Technique for providing information assistance including a concierge-type service

ABSTRACT

A user may access information assistance for a concierge-type service, whereby the user may make restaurant reservations, purchase goods and services, obtain movie listings, etc. with an agent&#39;s (or operator&#39;s) assistance. In accordance with the invention, the agent may suggest a vendor for providing the goods or services requested by the user, and attempt to fulfill the user request. The suggested vendor may be one of the preferred vendors pre-selected by the user; it may be one of the preferred vendors pre-selected by a group to which the user belongs; it may be one of the preferred vendors pre-selected by the provider of the concierge-type service; and it may be one of the preferred vendors pre-selected by a telephone carrier to which the user subscribes. The suggested vendor may also be a function of characteristics of the vendors that the user prefers, costs, etc. The invention resolves conflicts of preferences of different parties involved to come up with the suggested vendor.

FIELD OF THE INVENTION

The invention relates to a communications system and method, and moreparticularly to a system and method for providing information assistanceincluding a concierge-type service in response to a customer's call.

BACKGROUND OF THE INVENTION

Concierge services are typically provided by hotels. The methodgenerally employed is where a hotel guest, using the hotel roomtelephone, places a call to the hotel reception and asks to speak to thehotel concierge. The guest is connected to the concierge who thenlistens to the request of the hotel guest, such as a request for arestaurant reservation, and notes any preferences, such as the guest'spreference for outdoor dining. The concierge then suggests a service, anevent or restaurant in accordance with the guest's desires andpreferences. The suggestion is often based on the concierge's personalknowledge in the field, and/or by consulting a listing book ordirectory. Should the suggestion be satisfactory, the concierge willmake the necessary reservations and inform the hotel guest of thereservation details.

Concierge services are especially useful for a visitor who is unfamiliarwith an area's services, eating establishments or upcoming events. Theproblem with such a service is that it is restricted to the guests at aspecific hotel only. The concierge's suggestions, for practicalpurposes, can also often be biased, erratic or based on limited listingor directory information. In addition to the above, the hotel guest mayalso need to write down the reservation details, obtain directions andarrange transportation.

Furthermore, the whole process can be slow, as access to large listingsare often manually searched by the concierge. The concierge may also belimited by the type of search he/she can perform. He/She may not be ableto search for multiple preferences simultaneously, such as for examplean outdoor, non-smoking, vegetarian restaurant, in a specific area. Inaddition, the concierge may only be familiar with restaurants in aparticular area and therefore may be of little use to a hotel guest whois departing that day for another city.

Directory Assistance

Traditionally, directory assistance has focused on providing telephonenumber directory information only. Typically, a directory assistanceoperator receives a request from a caller for the telephone number of adesired party. The operator locates the required number from a listingdirectory and may either give the number to the caller or connect thecaller to the desired party.

Each year, a growing number of people spend a significant amount of timetraveling for business or pleasure. Mobile communication and portablecomputers have created an opportunity for these people to conductbusiness and communicate while on the move. Wireless telephones havebecome a standard business tool in this environment. Wireless telephoneusers may find current directory assistance services inconvenient ordifficult to use. Such users are usually away from their general workenvironments (for example, traveling in a vehicle), and thus may not beable to remember, or make a note of a desired number. Callers who wouldnormally be able to call upon secretaries or personal assistants attheir offices, may not have access to such assistance when traveling.The wireless telephone caller thus needs a comparable service to thatwhich they would experience in an office environment. While improvementsto telephone directory assistance have been made over the years, suchsystems do not fully address the needs of wireless telephone users.

The present assignee has redressed certain of the above-mentioneddifficulties by improving the traditional directory assistance serviceto eliminate the need to make notes of the desired number, or undertakea redialing exercise. Further, it has transformed the traditionaldirectory assistance service to an information assistance service whichalso provides driving directions, horoscope information, movie listings,sports information, etc. The present assignee has established acountry-wide network of information assistance or call centers that arecapable of providing its customers with nationwide informationassistance.

SUMMARY OF THE INVENTION

The marriage of an information assistance service and a traditionalconcierge service has been observed. The resulting concierge-typeservice is described, for example, in copending, commonly assigned U.S.application Ser. No. 09/520,306 (“the 306 application”) filed on Mar. 7,2000. For example, a user may access the concierge-type service to makerestaurant reservations, purchase goods and services, obtain movielistings, etc. with an agent's or operator's assistance. However, the'306 application did not address any conflicts in selecting a vendor(s)for providing the goods or services desired by the user, which may arisefrom preferences of different parties involved, e.g., the user, theprovider of the concierge-type service, the carrier to which the usersubscribes, etc.

In accordance with the invention, a vendor, suggested by theconcierge-type service to provide the desired goods or services, may beone of the preferred vendors pre-selected by the user, which may bespecified in a user profile. The suggested vendor may also be one of thepreferred vendors pre-selected by a group (e.g., a company, a sportsteam, etc.) to which the user belongs, which may be specified in a groupprofile associated with the user. Further, the suggested vendor may beone of the preferred vendors pre-selected by (or affiliated with) theprovider of the concierge-type service, which may be specified in aprovider profile associated with the user. In addition, the suggestedvendor may be one of the preferred vendors pre-selected by (oraffiliated with) a carrier to which the user subscribes, which may bespecified in a carrier profile associated with the user. As fullydescribed below, the suggested vendor may also be a function ofcharacteristics of the vendors that the user prefers, costs, etc. Theinvention resolves the aforementioned conflicts of preferences to comeup with the suggested vendor.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other features, aspects, and advantages of the presentinvention will become more readily apparent from the following detaileddescription, which should be read in conjunction with the accompanyingdrawings, in which:

FIG. 1 is a flow chart depicting a routine for accessing an enhancedtelecom service in accordance with the invention;

FIG. 2 illustrates the components of an information assistance systemaccording to the invention;

FIG. 3 illustrates an information network system according to apreferred embodiment including a wide area network;

FIG. 4 illustrates a first graphical user interface of the presentinvention;

FIG. 5 illustrates a second graphical user interface of the presentinvention;

FIG. 6 illustrates a third graphical user interface of the presentinvention;

FIG. 7 illustrates a fourth graphical user interface of the presentinvention;

FIG. 8 illustrates a fifth graphical user interface of the presentinvention;

FIG. 9 illustrates an arrangement for providing telephonic conciergeassistance in accordance with the invention;

FIG. 10 is a flow chart depicting an embodiment of the method by whichtelephonic concierge assistance is provided to a caller;

FIG. 11 is a flow chart further depicting an embodiment of the method bywhich telephonic concierge assistance is provided to a caller;

FIG. 12 illustrates an arrangement whereby information concerningfulfillment of a concierge request is provided to a caller;

FIG. 13 is a flow chart depicting a process for resolving conflictsbetween vendor selection criteria in fulfilling a concierge requestaccording to the invention; and

FIG. 14 illustrates an implementation of an algorithm for resolving theconflicts in accordance with an embodiment of the invention.

DETAILED DESCRIPTION

The invention is directed to providing to a user information assistanceincluding a concierge-type service. In prior art, information assistanceincluding, e.g., searching for a desired destination party's telephonenumber, is considered a special service. Information assistance servicecharges typically are tagged onto telecommunication charges forutilizing a carrier's network facility to complete the user's call tothe destination party. The information assistance service and thetelecommunication service typically are priced on different bases. Forexample, the information assistance service charges typically aredetermined on a per call basis whereas the telecommunication charges aredetermined based on the connection time, although the two differentcharges for an information assistance call may be consolidated in thesame bill to the user.

A new “enhanced” telecommunication (telecom) service concept has beendeveloped, which stems from a recognition of the multifarious servicefeatures affordable by an information assistance service, which havebeen developed over time and include, e.g., personalized servicefeatures, private directory and calendar service features, andconcierge-type service features described below. The enhanced telecomservice is born out of an anticipation of a user's or a destinationparty's taking advantage of the various information assistance servicefeatures, even though the user when initially making a call to thedestination party may have no intent to use any of the service features.In a preferred embodiment, the provider of the enhanced telecom servicehas both information assistance capability and network capacity forconnecting a user to a destination party. For example, an enhancedtelecom service provider may be an improved information assistanceservice provider having network capacity (e.g., PSTN, wireless, and/orprivate network capacity) at its disposal, e.g., by leasing capacity andequipment from a carrier. Thus, the enhanced telecom service providerhas end-to-end connectivity, readily providing information assistance toa user at his/her initiative during a call. With connectivity costswithin its control, the enhanced telecom service provider may charge forthe enhanced telecom service according to a single fee schedule,notwithstanding the fact that the user may have utilized bothinformation assistance and telecom services during the same call, forwhich in prior art are charged according to the respective feeschedules. For example, the provider may charge the enhanced telecomservice strictly on a connection time basis, e.g., 9 cents per minute ofthe call, regardless of the number of invocations of informationassistance and connections to different destination parties during thesame call. Another time-based arrangement may be a flat fee for aninitial block of minutes (e.g. $1.00 for the first 15 minutes) of calltime, after which there would be a fixed charge per minute. A flat feefor each call regardless of the call duration may also be practicalunder the present enhanced telecom service model. A “cafeteria” styleplan which may involve separate charges for each service provided may bepractical as well.

Advantageously, the enhanced telecom service model is conducive tosaving such administrative costs as would otherwise be incurred in priorart where the information assistance and telecommunication servicecharges are determined separately. Especially where the informationassistance service provider and the carrier are independent in priorart, the administrative needs of collecting off-line informationconcerning assistance service charges due the service provider,associating such charges with the corresponding telecommunicationcharges due the carrier, and combining both charges for billing a useris advantageously obviated by implementing the present enhanced telecomservice model.

However, it will be appreciated that even under the present enhancedtelecom service model, a provider may still levy extra charges on a userfor specific service features.

The enhanced telecom service may be accessed via a designated telephonenumber, e.g., 1010-XXX-XXXX, 800-XXX-XXXX number, etc. Such a designatednumber may be publicized in many ways. For instance, the number may beimprinted on a credit card (especially when services are charged to thecredit card), prepaid calling card, telephone charge card, etc. When auser access the enhanced telecom service via the designated telephonenumber, in accordance with another aspect of the invention, the user isafforded an option to begin the call with an information assistanceservice, as indicated at step 1003 in FIG. 1. If the user selects suchan option, the call is routed at step 1006 to an operator to provideinformation assistance in a manner described below. (The term “operator”used herein broadly encompasses entities that are capable of providinginformation assistance in a telecommunication environment, includingwithout limitation human operators, voice response/recognitioncapabilities, web/WAP-enabled operator services, and other automated andelectronic access.) Otherwise, if the aforementioned option is notselected, the user is prompted at step 1009 to enter the destinationnumber which the user wants to call, with the understanding that he/sheis able to invoke information assistance any time during the call. Infact, a technique for invoking information assistance and servicesduring a call by a caller or a called party is described, e.g., incopending, commonly assigned application Ser. No. 10/313,712 filed onDec. 6, 2002, which is incorporated herein by reference. For example,using the disclosed technique, a enhanced telecom service provider maymonitor for a predetermined signal such as a DTMF tone initiated byeither party's depressing a predetermined key on a telephone. Once onesuch signal is detected, an operator is conferenced into the call toprovide information assistance to the party(ies). At step 1012 theuser's call is routed to the destination party through atelecommunication network, wherein a device is used to monitor on thecall connection for the predetermined signal invoking informationassistance, as indicated at step 1015. Thus, depending on a detection ofthe predetermined signal, step 1015 may be followed by step 1006 forproviding information assistance (indicated by a dashed lineconnection). It should also be pointed out that step 1006 may befollowed by step 1009 (indicated by a dashed line connection) when, forexample, the information assistance provided at step 1006 includessearching for a desired destination number, and connecting the user tothe desired destination number.

In an alternative embodiment, the user may be provided with two enhancedtelecom service access numbers, one of which corresponds to starting theuser's call with an information assistance service, and the othercorresponds to allowing the user to call the destination numberdirectly, with the ability to invoke information assistance anytimeduring the call. In addition, different access numbers may be providedfor different branding.

A user when making a call through the enhanced telecom service may beidentified, e.g., by automatic number identification (ANI), by an entryof a user identification (ID), password, PIN, mother's maiden name,etc., or by voice recognition, voice printing, speaker verification orother identification techniques. The user may be afforded servicefeatures specified in a user profile, e.g., identified by the user ID.The user profile may contain personal preferences which may be selectedby the user during an initial registration with the enhanced telecomservice provider, and which may be modified subsequently. Animplementation of the user profile to render a personalized informationassistance service is described, for example, in copending, commonlyassigned U.S. application Ser. No. 10/323,287 filed on Dec. 19, 2002,which is incorporated herein by reference.

For example, the user may be an employee of a company, which subscribesto the enhanced telecom service. The user profile may specify theinformation assistance service features selected by the company, andidentify access to the company's corporate directory and othercompany-specific services. In addition, if the user utilizes thecompany's facility to make an outside call, the user may be prompted foran entry of a charge number authorized by the company to fully takeadvantage of the enhanced telecom service.

Billing for the enhanced telecom service may be by credit card, prepaidcalling card, debit card, direct billing to subscribers, or billingthrough a third party which may already have a billing relationship withthe subscribers for other services, e.g., utilities.

A user may access information assistance for the aforementionedconcierge-type service, whereby the user may make restaurantreservations, purchase goods and services, obtain movie listings, etc.with an agent's (or operator's) assistance. The agent may suggest avendor for providing the goods or services requested by the user, andattempt to fulfill the user request. In accordance with the invention,the suggested vendor may be one of the preferred vendors pre-selected bythe user, which may be specified in the user profile. The suggestedvendor may also be one of the preferred vendors pre-selected by a group(e.g., a company, a sports team, etc.) to which the user belongs, whichmay be specified in a group profile associated with the user. Further,the suggested vendor may be one of the preferred vendors pre-selected by(or affiliated with) the provider of the concierge-type service, whichmay be specified in a provider profile associated with the user. Inaddition, the suggested vendor may be one of the preferred vendorspre-selected by (or affiliated with) a telephone carrier to which theuser subscribes, which may be specified in a carrier profile associatedwith the user. As fully described below, the suggested vendor may alsobe a function of characteristics of the vendors that the user prefers,costs, etc. The invention resolves conflicts of preferences of differentparties involved to come up with the suggested vendor.

With reference to FIG. 2, information assistance system 100 according toan exemplary embodiment of the invention is depicted. One or moreexternal communication links 102, e.g., T1 communication links, connectinformation assistance system 100 to a telecommunication network, e.g.,PSTN, wireless telephone network, private network, or a combinationthereof. Where an information assistance service provider is independentfrom a carrier as in prior art, information assistance system 100 isadministered by the information assistance service provider while thetelecommunication network is administered by the carrier. However, wherethe above-described enhanced telecom service concept is implemented,both system 100 and the telecommunication network are administered bythe enhanced telecom service provider. Communication links 102 connectto switching matrix platform 104, which is connected to switch hostcomputer 106 via switch data link 108. In an alternative embodiment,switch host computer 106 is coterminous with switching matrix platform104.

Switching matrix platform 104 is attached via a T1 communication link tochannel bank 110, and from there connects to operator channel 112 and aplurality of operator and fulfillment agent telephones 116 and 117respectively. Operator telephones are located at each of one or moreoperator positions (represented by the numeral 114 in FIG. 2), andfulfillment agent telephones are located at each of one or morefulfillment agent positions (represented by the numeral 119 in FIG. 2).Using operator data terminal 118, an operator at operator position 114accesses one or more system servers 120, which are interconnected viadata network 122. Switch host computer 106 is also connected to datanetwork 122. Finally, switching matrix platform 104 is connected to oneor more voice servers, which are described below. Each connection to avoice server employs a T1 voice server link (a first voice server link124 is shown in FIG. 2).

The data network 122 may, but not necessarily, also further connect to adirectory listing/concierge (DL/C) database server 136 and a callerprofile database server 134. The caller profile database server 134stores detailed information about a subscriber. Such details may includethe subscriber's name, contact details, preferences, dietaryrequirements, likes and dislikes, past logged activities, etc. The DL/Cdatabase server 136 may contain directory listing information onrestaurants, events, accommodation, transportation, travel informationand booking, stock prices, weather and other services such as grocery orflower delivery, etc.

As stated above, communication links 102 provide telephone connectionsto information assistance system 100 for incoming information assistancecalls and also provide access to the external telecommunication networkover which outgoing calls are placed. Communication links 102 may, in anillustrative embodiment, be comprised of one or more T1 communicationspans which are known in the art. In such an embodiment, each individualcall over a T1 span, whether into or out of switching matrix platform104, utilizes one of the 24 individual channels into which a T1 span issegmented, each channel providing two-way communications.

It will be recognized by one skilled in the art that multiple instancesof switching matrix platform 104 may be incorporated into thetelecommunication network or information assistance system 100 withoutexceeding the scope of this invention.

In this illustrative embodiment, switching matrix platform 104 supportsdigital T1 telephone circuits and includes digital signal processingcircuitry which provides the requisite conference capability (describedbelow), SS7 message generation/detection capabilities, and dual tonemulti-frequency (DTMF) and multi-frequency (MF) tonegeneration/detection capabilities. With respect to the SS7functionality, the switching matrix platform acts as a signaling node,also known as a service switching point.

Switch host computer 106 stores and executes computer-readableinstructions for purposes of, among others, configuring and operatingswitching matrix platform 104 and directing the transfer of callsthrough switching matrix platform 104. It also directs the playback ofrecorded messages to callers connected to information assistance system100. Pre-recorded greeting and closing messages played for callers arerecorded in the voice of the operator to whom the caller will be, orwas, connected, or in some other voice. Switch host computer 106 directsthe playback of the appropriate message by identifying the operator andthe inbound channel 102 a the caller is connected to and specifying themessage to be played.

Further, switch host computer 106 maintains call data for eachinformation assistance call connected to information assistance system100. The call data stored on the host computer consists of the mostrecent assistance request received from each caller, and includes one ormore of: the calling telephone number, the date and time of the caller'sconnection to information assistance system 100, the T1 span and channelthe caller is connected to, the caller's desired destination telephonenumber, the status of the caller's previous information assistancerequest, which operator assisted the caller, etc.

Additional call data is stored on system servers 120, as describedbelow. The call data stored on switch host computer 106 and systemservers 120 are provided to information assistance providers when acaller makes multiple information assistance requests in one call toinformation assistance system 100. By considering the collected calldata, such as the information that was provided to a caller in aprevious request, an information assistance provider can tailorsubsequent assistance to be more effective.

Switch host computer 106 also directs the transfer of informationbetween itself and system servers 120 (via data network 122) as well asbetween system servers 120 and switching matrix platform 104 andoperator position 114/fulfillment agent position 119 (via channel bank110 and operator channel 112).

Operator position 114 includes means by which a live operator receivescalls, determines caller's informational needs, searches for andretrieves information from system servers 120, provides information tocallers, and initiates outgoing calls. In an exemplary embodiment of theinvention, an operator at operator position 114 is provided with atelephone headset 116 for interacting with callers, and data terminal118, connected to data network 122, for interacting with system servers120.

Each operator and fulfillment agent is equipped with a terminal 118 and121 that includes a monitor and keyboard with associated dialing pad.The operator terminals are coupled over a data network 122 to a dataserver 120 a, allowing an operator to access the data in data server 120a through the operator terminals 118 and fulfillment agent terminals121.

System servers 120, which are interconnected via data network 122,include one or more data servers 120 a which provide and manage dataservices within information assistance system 100. Data servers 120 amaintain databases containing telephone and business directories,billing information, and other information in computer-readable form tobe searched by operators in response to callers' requests. As introducedabove, data servers 120 a also store call data for later retrieval byinformation assistance providers furnishing subsequent assistance to acaller. The call data stored on data servers 120 a illustrativelyinclude how and where an information assistance provider searched forinformation to satisfy a customer request, the information retrieved bythe assistance provider, how that information was displayed for theassistance provider, and the form in which it was communicated to thecaller. Unlike switch host computer 106, data servers 120 a save calldata concerning all requests made by a caller during one call toinformation assistance system 100, not just the most recent request, butfor a predetermined period of time (illustratively, one hour).

Billing information is stored in the form of call records, which arecreated for each customer call into information assistance system 100.They contain data such as the caller's telephone number, the date andtime of the caller's connection to information assistance system 100,the dates and times of attempted connections to destination parties, theduration of each call leg, etc. A call record is updated each timeinformation assistance is rendered to the associated customer, and isclosed when the customer disconnects from information assistance system100.

The software used to create and manipulate the databases on data servers120 a is known in the art of computer software and allows informationassistance providers to search the databases by name, address, type ofgoods or services, geographical region, etc. In FIG. 2, switch hostcomputer 106 and data servers 120 a are depicted as distinct entities;in an alternative embodiment they are coterminous.

System servers 120 also include one or more voice servers (a first voiceserver 120 b is shown in FIG. 2) that provide, in alternativeembodiments of the invention, all or a subset of the operator functionsprovided by a live operator at operator position 114. For example, voiceservers store and deliver messages that live operators would otherwisebe required to frequently repeat for callers, such as greetings, closingmessages, and the caller's requested telephone number.

The voice server 120 b, also called a voice response unit (VRU), isincorporated into the system to play the frequently repeated parts of anoperator's speech, namely the various greetings and signoffs (orclosings), and the caller's desired telephone number where requested.Not only does this system provide a voice-saving and monotony-relieffunction for the operators, it performs a “branding” function (i.e. thepre-recorded messages incorporate the name of the service providerthrough which the caller was routed to the information assistanceservice), and it also reduces the amount of time an operator is actuallyconnected to a caller. The voice server may also contain a voicerecognition system for receiving verbal input from a party connected tothe voice server. Alternatively, the voice server may be part of asystem that performs all operator functions in an automated manner.

The DL/C database server 136 and data server 120 a provide operatorswith the means to search for a caller's desired party, and determine theappropriate telephone number. In the preferred embodiment, the databasesprovide the capability to search not just by name and address, but alsoby type of goods/services and/or geographical region, or by any otherattribute in the caller record, including phone number. For example, thepreferred database can answer queries soliciting the names/numbers ofChinese restaurants on a given street. Data indexed in this fashion isusually not commercially available, so the present assignee starts witha commercially available database file (e.g. the Information assistanceDatabase Source available from U.S. West), and enriches it by addingfurther data manually. The databases may be SQL relational databases.SQL (Structured Query Language) is a standard interactive andprogramming language for getting information from and updating adatabase. Queries take the form of a command language that lets youselect, insert, update, find out the location of data, and so forth.Database servers 134 and 136 may also be located at a centralizedlocation. Each remote LAN thus accessing these databases via the LAN.Servers 120 a and 136 are separated for ease of explanation, but may beincorporated into a single database.

Desirably, the results of the database search presented on theoperator's terminal 118 or fulfillment agent's terminal 121 are notalphabetized prior to display, but rather are presented in the orderlocated by the database search engine. (If desired, a deliberaterandomization of order could be effected before display.) Businesses atthe beginning of the alphabet are thereby not unduly favored by callersusing the information assistance service. In the alternative, businessescan bid to be listed at the beginning of the list.

The database software itself may be conventional, preferably arelational database such as is available from Sybase, Oracle, etc., ormay be unconventional or proprietary.

Directory listing information may be obtained from a number ofcommercially available services and/or may be manually entered into theDL/C database server 136.

In an illustrative embodiment, voice server 120 b is connected toswitching matrix platform 104 by voice server link 124 and to switchhost computer 106 and data servers 120 a via data network 122. Eachvoice server connects to switching matrix platform 104 via a separatevoice server link.

Voice server link 124 provides voice connections between switchingmatrix platform 104 and voice server 120 b, thus providing means bywhich callers may be connected to voice server 120 b and receiveautomated operator assistance. Voice server link 124, in an illustrativeembodiment of the invention, is comprised of one or more T1 spans, witheach one of the 24 channels of each span providing two-waycommunications.

At appropriate stages in a call progression, the switch host computer106 initiates a voice path between the voice server and the switchingmatrix platform 104 such that the caller, or the caller and theoperator, are able to hear whatever pre-recorded speech is played onthat circuit by the voice server. Computer 106 then instructs the voiceserver, via the data network, what type of message to play, passing dataparameters that enable the voice server to locate the messageappropriate to the call state, the service-providing telephone company,and the operator. The recording density used is high enough to provide agood enough quality of message playback that most users of the systemshould be unaware they are listening to a recording.

FIG. 3 illustrates an information network system in accordance with theinvention, which includes a wide area network (WAN) 30 covering a widecoverage area. The WAN 30 can be an Internet-based network such as theworld wide web or can be a private intranet based network. According toa preferred embodiment, the WAN 30 covers an entire region (e.g., theentire eastern seaboard of the United States), an entire country (e.g.,United States) or group of countries (e.g., all of Canada, Mexico andthe United States). The WAN 30 connects a plurality of operators andfulfillment agents dispersed throughout the wide coverage area in aplurality of information assistance centers 21, 22, 23, 24, 25, 26 and27. Each of the information assistance centers 21, 22, 23, 24, 25, 26and 27, which in this instance comprises information assistance system100 described above, covers one or more regional coverage areas. One ormore information hubs 10 are also included in the WAN 30. An informationhub 10 contains one or more databases including concierge database 20and one or more servers including concierge server 28 which areaccessible by the operators, and fulfillment agents in system 100.

Invocation of Information Assistance During a Call

In an illustrative embodiment, the user calls the aforementioneddesignated number to access the enhanced telecom service. The call isrouted through a telecommunication network to an information assistancecenter and terminated at switching matrix platform 104 of system 100 inthat center. Referring to FIGS. 1 and 2, once a call is received, hostcomputer 106, in cooperation with voice server 120 b, carries out step1003. If the caller opts to begin the call with information assistance,the call is routed to, or queued for, an operator. Otherwise, hostcomputer 106 causes voice server 120 b to prompt the caller to enter adestination number. In response to an entry of the destination number,platform 104 routes the call through an outgoing T1 span 102 to adestination party at the destination number. After the connection ismade, either the caller or the destination party may invoke aninformation assistance service, and the operator would join the callthrough platform 104 as a conferenced party in a 3-way conference call.Either party could then request the operator to render informationassistance, e.g., directory assistance, a concierge-type servicedescribed below, etc. Invocation of an information assistance servicemay be realized by either party's pressing a key (such as “0,” “#,” or“*”) or voicing a command (e.g., uttering “operator”) while a digitalsignal processing device in platform 104 is programmed to monitor thecall connection for the resulting DTMF tone or voice command (i.e., apredetermined signal).

It should be noted at this point that after the operator joins the call,the caller may exercise different options by voice commands or bypressing predetermined keys on his/her telephone (DTMF tones),respectively. For example, a first option may be allowing the caller tocontrol the destination party's ability to hear any conversation betweenthe caller and the operator. A second option may be allowing the callerto disconnect the destination party from the call so that the caller canhave an exclusive conversation with the operator.

Concierge-Type Service

Operators are generally provided with web browser capabilities,telephone facilities as well as fully-featured operator user interfaceapplications which facilitate the searching and retrieval of informationfrom database sources. According to the present invention, the operatorsare also capable of receiving requests from calling customers throughoutthe system of FIG. 2 for requests for concierge-type services. When arequest for concierge-type services is received by an operator, theoperator completes a record of the request. This record is referred toas a “ticket.”

A web-based form of ticket is accessible by each of the operators overthe WAN. One such form is shown in FIG. 4. To complete the ticket,information regarding the concierge services request is gathered in anumber of ways. The customer may, for example, specifically request aparticular restaurant or a particular airplane flight or hotelreservation. Using a request for a restaurant reservation as an example,the operator may solicit from the calling customer their first choicefor a restaurant, their second choice for a restaurant, preferredseating times, alternative seating times, etc. In this case, informationmay be directly entered into the form.

More typically, however, the customer will have certain desires—e.g., avegetarian outdoor restaurant in “Cardiff by the Sea” as per FIG. 3, ora midnight flight from New York's JFK Airport to San Diego Internationalairport. In this case, the operator will search the various databases athis/her disposal to compile a specific request for the calling customer.The operator may then obtain directly from the calling customerinformation regarding preferred seating times, alternative seatingtimes, etc.

Information, such as who the calling customer is and contact numbers sothat the system can confirm with the calling customer when the requestis fulfilled, are advantageously obtained from information regarding thecalling customer residing on the system databases. The systemautomatically uses this database information to complete part of eachticket.

According to the present invention, the operator's web browser providesa direct connection to either a server in one of the information hubs,or to a central server, in the system. In essence, the operatorinterface and the server are in a client-server arrangement. Thus, ineffect, when the ticket is filled-in, the operator sends the ticket overthe WAN to the concierge database to be picked up for fulfillment.

Fulfillment agents fill the requests for concierge services received bythe operators. Fulfillment agents are provided similar web browser andtelephone facilities to those provided to the operators. By means of theweb browser, the fulfillment agent has access to one or more web pages.These web pages provide the fulfillment agents with informationregarding outstanding requests for concierge services. (The public'saccess to these web pages is restricted so the privacy of the callingcustomer is protected.) When a ticket created by an operator needsfulfillment in a particular regional coverage area, the web page for thefulfillment agent servicing that regional coverage area will change andindicate that a ticket needs to be processed. The system periodicallyrefreshes the web pages to keep fulfillment tickets current.Advantageously, the fulfillment agents are located throughout thecoverage area. A fulfillment agent preferably is an individual withspecialized knowledge of the regional coverage area and the servicesprovided therein so they can effectively fulfill the requests for localconcierge services. The fulfillment agent may be a call centersupervisor, an underutilized operator or a task specific employee in aparticular information assistance center.

According to the preferred embodiment, a centralized conciergerelational database is maintained in a central information hub. Thepreferred database being a structured query language (SQL) relationaldatabase, although other relational and non-relational systems may beimplemented without departing from the scope or intent of the presentinvention. A motivation behind maintaining the concierge database in asingle information hub is that such centralization provides thecapability of receiving a request for concierge services in a firstregional coverage area where the requested services are in a secondregional coverage area. For example, suppose a business traveler in NewYork intends to fly later that day to San Diego to have dinner thatevening in “Cardiff by the Sea.” The traveler dials the New Yorkinformation assistance center. The traveler informs the operator whoreceives the call in the New York center of his/her travel plans andhis/her desire to eat at a “Cardiff by the Sea” restaurant. The operatorin the New York center creates the ticket for the business traveler.That ticket is recorded in the centralized concierge database. Theserver will then automatically route the ticket to a fulfillment agentin the San Diego information assistance center. As a result, the ticketappears on the screen of the San Diego fulfillment agent in the SanDiego information assistance center.

Each information assistance center has an identification number and/orname. When an operator creates a ticket, the system by default assignsthe ticket to the information assistance center where it was created.This is accomplished by assigning the originating center'sidentification number/name to the ticket. However, the operators havethe capability to change this assignment, by manually inputting theidentification number/name of the center where the request for conciergeservices is to be directed. In the example above, the operator in theNew York center would change the identification number/name of thefulfilling center from the default of the New York center to the SanDiego center.

While implementation of full concierge database server in eachinformation assistance center adds administrative overhead, the presentinvention encompasses embodiments where the concierge database server isnot centralized in a single information hub but is instead distributedthroughout the system. Similarly, in a further alternative embodiment inaddition to the centralized database, one or more localized conciergedatabases may be maintained locally to keep, maintain and update traveland concierge-type information relevant to only that particular locale.Further, while the concierge database is described and depicted as aseparate and independent database from the other maintained databases(e.g., information assistance database or a customer informationdatabase), it is well understood by those skilled artisans that theconcierge database may reside as part of one or more of the databasesmaintained by the organization.

Referring to FIG. 3, both the operators and fulfillment agents haveaccess to the concierge database(s). The WAN 30 connects the operatorsand fulfillment agents to the concierge database(s) 20. In generalterms, the concierge database maintains information regarding conciergeservices. For example, the concierge database includes customer creditcard information, and information regarding the status of the requestfor concierge service. Typically, restaurants and hotel listings aremaintained on an information assistance database separate from customerand ticket data. However, in an alternative embodiment, all conciergeinformation is maintained on a separate concierge database.

A further network is provided to connect the fulfillment agents toproviders of services, such as airlines, hotel chains, restaurants,travel agents (including web-based travel service providers such asExpedia, Priceline.com, Travelocity). Such a network connection may be apublic or private network (such as a VPN).

FIG. 4 illustrates a graphical interface used by an operator to generatea ticket. The interface is designed so that the operator asksappropriate questions to accumulate sufficient information to fill thecustomer's request. The intent of the interface is that the ticket canbe filled by the fulfillment agent without further interaction betweenthe system and the calling customer. However, should further interactionbe required, the interface includes contact information so a follow-upphone call can be placed to the customer, either to advise the customerthat the request has been filled or to obtain further information so therequest may be filled. The interface shown in FIG. 4 is directed to arequest for a restaurant reservation. It should be appreciated thatdifferent interfaces may be used for different types of requests. Forexample, an interface may be specifically designed for hotelreservations, airplane reservations or car reservations. The operatorsmay select via menu the appropriate interface for the customer request.Alternatively, the appropriate menu may be selected automatically by thesystem based on skills-based routing or by dialed telephone number.

Referring now specifically to the interface shown in FIG. 4, theinterface includes a plurality of sets of fields, each of the fieldscapable of capturing data input. The first set of fields relates to theidentification of the calling customer. The first of the three fields inthe first set is the “Name of Reservation” indicating the callingcustomer requesting the reservation. The second field is the “CallerMIN” indicating the calling customer's Mobile Identification Number(MIN). The third field is the “Carrier ID” indicating the carrier whoprovided the call to the calling center. The system may be designed toinput the information into these fields automatically. The callingcenter's switching equipment described herein is capable of detectingthe information associated with these fields directly from the incomingcall. Thus, when an operator selects this interface in connection with acall, these fields may automatically be filled in. Additional fieldsrelating to the identification of the calling customer may also beautomatically filled in and displayed. The additional fields include thehome address of the calling party and the present location of thecalling party to the extent such information is available from thecarrier, by GPS or other locating means.

The next two sets of fields relate to the particular restaurant desiredby the calling customer. The first set of fields relate to the firstchoice for the restaurant, its phone number, and its address. Similarly,the second set of fields relate to the second choice for the restaurant,its phone number and its address. The fields titled “First ChoiceRestaurant” and “Second Choice Restaurant” are typically completed withinformation solicited by the operator from the calling customer.However, records kept in the databases may include a list of favoriterestaurants for this particular customer. In addition, there may be morethan one list of favorite restaurants maintained, one for each of thedifferent cities frequented by the calling customer. In anotherembodiment of the present invention, the operator may offer the callingcustomer recommendations of restaurants from well-known lists ofrestaurants such as those generated by Zagats, Sidewalk.com or anotherdirector database maintained by the system. Advantageously, once the“restaurant names” fields are completed, the remaining fields relatingto the phone number and address of the restaurants may automatically befilled in by information obtained from the information assistancedatabases maintained in the system. Relevant database information canalso be manually transferred by the operator into the ticket fields.

The next set of fields in the operator interface relate to the detailsneeded for making the restaurant reservation. The first field is titled“Date of Reservation” which is the date the customer wants thereservation. This field is completed with information solicited by theoperator from the calling customer. The date of the telephone call isused as the default and may be modified by operator input to a futuredate if requested by the caller. The next field is titled “Number inParty” and corresponds to the size of the party for which thereservation is sought. This field is completed with informationsolicited by the operator from the calling customer. This fieldadvantageously may default to information contained in a record entry ina database corresponding to the calling customer's preferred size ofdining party. The third field is titled “Preferred Time” whichcorresponds to the time the calling customer desires the reservation.This field is completed with information solicited by the operator fromthe calling customer. This field advantageously may default toinformation contained in a record entry in a database corresponding tothe calling customer's preferred dining hour. The fourth field in thisset is titled “If unavailable then from:” which corresponds to thecalling customer's acceptable dining times. Again, this field iscompleted with information solicited by the operator from the callingcustomer and advantageously defaults to a record entry in a databasecorresponding to the calling customer's preferred dining hours.

The last set of fields in the operator interface corresponds to contactinformation. The contact information fields comprise two sets of fieldscorresponding to a contact name, contact method, and telephone number.Typically, this information advantageously defaults to informationcontained in a record entry in a database corresponding to the callingcustomer's preferred contact names, methods and phone numbers. Theoperator is expected to confirm with the calling customer thecorrectness of this information. Regarding the contact method, apulldown menu is provided. Any number of contact methods are availableincluding phone, wireless phone, pager, fax, and email. Whenever oneparticular method is chosen, the corresponding telephone number and/oremail address appears. It is understood that the same name may beentered in both contact name fields but two different contact methodsmay be chosen, for example, phone and pager.

A notes field not illustrated in FIG. 4, is an additional field in whichthe operator may type in comments such as special dietary requirements,special seating requests, etc.

It should be noted at this juncture that in accordance with theinvention, the information in the ticket is initially used by theoperator, who is communicating with the calling customer requesting theconcierge-type service, to attempt to fulfil the customer's request inreal time in a manner described below. When such an attempt isunsuccessful, the ticket is then forwarded to a fulfillment agent tofulfil the request off-line.

A further field not illustrated in FIG. 4 is the field associated withthe center targeted to fill the request off-line. As describedpreviously, the system uses the center which generates the ticket as thedefault fulfillment center. However, in instances in which the callerseeks concierge services outside the generating center's regional area,the operator will modify the ticket to direct the ticket to theappropriate fulfillment center. In a preferred embodiment, the system,automatically recognizes when the request for concierge services areoutside the generating center's regional area and will prompt theoperator if he/she wants to direct the ticket to a more appropriatecalling center.

Some forms of tickets according to the preferred embodiment areillustrated in FIGS. 5-8. Referring to the form of ticket illustrated inFIG. 5, this ticket is presented by the system to a fulfillment agentsitting in the information assistance call center which will fulfill theticket, in this example the San Diego call center. Via the WAN, theserver in the information hub directs a ticket to the display of a SanDiego fulfillment agent. The ticket provides the fulfillment agent withgeneral information regarding a customer's request for conciergeservices. For example, with the ticket shown in FIG. 5, the fulfillmentagent is provided with information regarding the identification of theticket, the date and time of the next action to fill the request, thedesired reservation date and time, the name of the requesting customer,the name of the target restaurant and the status of the request.

A first field is labeled “ID” and corresponds to the identification ofthe particular request for concierge services. The ticket is linked inthe database to other records regarding the concierge services requestsuch as all of the information taken down by the operator in generatingthe request. The fulfillment agent can access these additional recordsby selecting the ID field. (Because the ticket is presented to thefulfillment agent in the form of a web page, the fulfillment agent mayselect the ID field by means of a mouse click. The system serverrecognizes the mouse click and presents information to the operator.)

It is understood that a fulfillment agent will usually attempt to fillmore than one ticket at a time. Thus, a fulfillment agent willnecessarily have the capability to step through the various ticketscurrently at the fulfillment call center that require fulfillment. Thisadvantageously allows the fulfillment agent to prioritize which of thethen-pending tickets he/she will attempt to fulfill. Server software mayalso automatically prioritize tickets, allowing the fulfillment agent tooverride such prioritization if necessary. The concierge database may besearchable by any and all of the fields in the request, but preferablyby the restaurant or customer name. In FIG. 5 it is shown that the agentis provided on his/her screen, facilities to search requests byrestaurant name or by reservation name. In addition, the fulfillmentagent may step through the tickets pending at that call center, one byone, by page-up and page-down keys, or by back and forward keys on theweb browser interface.

The system creates an environment to ensure that tickets are respondedto by fulfillment agents in such a way so as to maximize the probabilitythat customers' requests are filled. One of the methods that the systemimplements towards this end is to prioritize, schedule and record all ofthe actions taken by the fulfillment agents on each request. Thus, thesystem advantageously minimizes the amount of guess work associated withthe request. Instead, it provides each fulfillment agent with clearinstructions when attempts to fill a request should be made. The fieldlabeled “Next Action Date/Time” is integral in this process. It informsthe fulfillment agent of the time and date that the agent should attemptto fill the customer's request. The system advantageously includes analarm subsystem which automatically signals the fulfillment agent thatan action should be taken toward the fulfillment of the request.

In terms of prioritization, the system employs one or more queues whichallow the system to process tickets based on next action time. Dependingupon the availability of system resources, the system may assign aplurality of fulfillment agents to each of the queues to maximize theprobability of request fulfillment. Each ticket's next action time ispreferably based on when an action last took place. A ticket's nextaction time may be set as follows:

1. No further action required as of midnight of the reservation date.2. Currently needs further processing.3. Needs more processing as target telephone was busy.4. Needs more processing as targeted telephone had no answer.5. Fulfillment agent may override the next action time.

More urgent tickets may be processed before less urgent ones. The systemweighs a number of factors in determining which of the tickets are mosturgent. These factors include the proximity between the current time andthe reservation date and time and the duration of time that the requesthas been under the status “Requires Fulfillment.” In addition,particular customers may warrant higher or different priority treatment.With these requests, the systems may place these tickets ahead of othertickets in the queue. Alternatively, the system may employ two queues,one for priority customers and one for non-priority customers. Specialfulfillment agents, such as those having special language skills orthose having more years of experience on the job, may be assigned to thepriority queues.

Scheduling and recording of the processing of tickets is now describedin connection with FIGS. 6-8. FIG. 6 illustrates a ticket after itscreation. The ticket comprises a request section and an event section.The request section appears just below the event section and is simplythe request as taken down by the operator as described above inconnection with FIG. 4. The fulfillment agent may scroll up and down thepage to view the different portions of the ticket.

The event section is illustrated in FIGS. 7 and 8. The event sectionsare essentially a menu-driven table. The event table facilitates thescheduling and recordation of all of the actions taken upon a particularrequest. A time and date stamp identifies when the last action was takenupon the request. Next, a menu driven list sets forth all of thepermissible actions that may be taken with respect to the request. Thelist of permissible actions include calling the first restaurant,calling the second restaurant, contacting the first customer contact,contacting the second customer contact, or simply viewing the request.Additional action types may be added, as needed. One of the majoradvantages of the present invention is the ease by which these actionsare taken by the fulfillment agent. Upon selection of a particularaction, the information assistance center automatically retrieves thenumber or routing information of the appropriate party (e.g., thetelephone number of the first or second restaurants or the pager oremail address of the first or second customer contact) from the ticketrecord and may thereafter attempt to establish a connection with theappropriate party. The information assistance center of the presentinvention includes one or more voice and/or data connections whichprovide connection to a public network over which outgoing calls ormessages may be placed. Because of this environment, when thefulfillment agent selects a particular action in the menu, a connectionto the appropriate party may be established without further action onthe part of the fulfillment agent. This eliminates the requirement thatthe fulfillment agent look up the telephone number in some database(whether it be a phone book or computer database), manually dial thetelephone number, redial if a misdial occurs, look up a second numberfor the second restaurant, and so on. Thus, the present inventionsignificantly reduces the time and effort associated with providingconcierge services. The fulfillment agent may also, if desired, manuallydial the desired telephone number.

The next column in the event table is a menu driven list of the resultsof the last action. The list of permissible results of the last actioninclude both the successful completion of an action (e.g., reservationmade at desired time, customer contact notified and reservationconfirmed, etc.), incomplete attempt to complete action (leaving messageon answering machine of restaurant, being placed on waiting list ofrestaurant, reservation available but outside range of time, unable tocontact person, etc.) as well as the failure to complete a requestbecause of the inability of the restaurant to meet the customer request(no reservation within range requested, no tables available, etc.). Inaddition, any of the possible network communication events such asring-no-answer, busy, or network problem may be result of last action.These network communication events may advantageously be detected by theinformation assistance center and automatically entered into the list.

The next column in the events table is a place for the fulfillmentagent, if applicable, to write any notes. These notes, along with theremainder of the ticket, allow a second fulfillment agent to pickupwhere a first fulfillment agent left off and continue processing thefirst fulfillment agent's ticket.

A ticket has a current status. The ticket may be “new.” A “new” ticketindicates there is a first action to be taken for the reservationrequest. The ticket may “require fulfillment.” A ticket “requiringfulfillment” indicates a first action has been taken but further actionsare required. The ticket may “require customer notification.” A ticketrequiring customer notification indicates that the customer must benotified because either the reservation has been successfully completedor there was a failure to complete the reservation and no other actionsare possible. The ticket may also be “canceled” or “closed” indicatingthat the customer has canceled the request or that the request has beencompleted and the ticket has been closed. A “notified” ticket indicatesthat the customer has been informed of the status of the request.

The event section of the ticket further includes a next actiontime/date. Whenever further actions are required on the ticket, thesystem automatically establishes a time and date for the next furtheraction to be taken. The system uses a simple algorithm to establish thetime and date for the next action. So long as there is sufficient timebetween the current time and the time by which the reservation must bemade, the next action time/date will be set at regular intervals (forexample, every 15 or 30 minutes). However, when the time between thecurrent time and the time by which the reservations must be made drawsnear, the next action time/date will accelerate to ensure the customeris notified. This auto next action time may be manually overridden.

In addition to off-line fulfillment of concierge requests by afulfillment agent (i.e. after the caller has disconnected), conciergerequests may be fulfilled in “real time,” that is, after the caller hasconveyed his/her request to the operator but before the caller hangs up.Of course, this aspect of the invention allows information regardingattempts to fulfill the request, such as confirmation information, to begiven to the caller before the caller hangs up.

One way of achieving real time fulfillment of concierge requests is tohave the caller wait, either by putting him/her on hold or otherwise,while the operator uses a second, outgoing telephone line to attempt tofulfill the concierge request. For example, if the caller tells theoperator he/she wants a reservation at the Tavern on the Greenrestaurant in Manhattan, the caller could be placed on hold while theoperator uses a second telephone line to call Tavern on the Green tomake the reservation. The operator would then take the caller off holdand convey to the caller the results of the attempt to make thereservation.

This manner of providing real time concierge request fulfillment has theadvantage of being relatively easy to implement, while at the same timeoffering a number of features and advantages to callers which would notbe available to the caller if the caller was simply given the telephonenumber of an establishment, or connected by the information assistancecenter to an establishment, and left to fulfill his/her own conciergerequest. For example, because many users of concierge and informationassistance services employ wireless or other mobile devices to requestsuch services, they frequently will not have a pencil and paper handy,making it inconvenient for them to take down the names of all theestablishments which can potentially fulfill their concierge requests.In addition, users of mobile devices, particularly when they are incars, want to dial as few telephone numbers as possible.

The advantages to callers of this aspect of the invention can beillustrated by the example of a caller desiring a reservation at anItalian restaurant having a Zagat Survey food rating of 26-30 on theeast side of Manhattan between 40th and 70th streets at 8:30 thisevening. The concierge service provider (conveniently termed herein“Concierge Provider,” which in some aspects of the invention will alsobe an information assistance provider including an operator) couldprovide the caller with the names of all the Italian restaurants thatsatisfy the caller's geographic and quality requirements, but the callerwill likely have no facility for writing this information down.Alternatively, the operator can read the restaurant options to thecaller and the caller can be connected to his/her first choicerestaurant directly by the Concierge Provider, but if, for example, thatestablishment does not have a reservation available at the time desiredby the caller, the caller will have to redial the Concierge Provider andstart the process all over again. Off-line fulfillment of thereservation request might not be satisfactory because, for any number ofreasons, the caller may need or want to know what his/her plans for theevening are in short order. Therefore, according to this aspect of theinvention, the caller would simply convey his/her request to theConcierge Provider and then hold while the Concierge Provider attemptsto fulfill the request.

A caller will, however, sometimes prefer to attempt to fulfill his/herrequest for a concierge service himself/herself. In this event, theConcierge Provider can provide the return-to-operator feature describedin U.S. Pat. No. 5,797,092 to enable callers to be connected to vendors(e.g. restaurants) to fulfill their own concierge requests while at thesame time offering them fast and convenient access to additionalconcierge, information assistance and/or other services with the push ofa button (e.g. the “*” key) if, for example, any individual attempt tofulfill a concierge request is unsuccessful (of course, such access canalso be provided if the attempt is successful). Further conveniences canbe offered, such as storing information regarding the caller's initialconcierge request and all subsequent attempts to fulfill it, and makingthis information available to whichever operator the caller is connectedto after invoking the return-to-operator feature. In this way, thecaller can return directly to where he/she left off immediately afterinitiating the return-to-operator capability.

Thus, for example, in the scenario described above in which the callerdesires a reservation at an Italian restaurant of a defined quality onthe east side of Manhattan between 40th and 70th streets at 8:30 thisevening, the caller would be given the names of Italian restaurantswhich satisfied his/her geographic and quality requirements, and thecaller would select one. The Concierge Provider would then connect thecaller to the restaurant he/she selected, storing the caller's originalrequest, which restaurants satisfied the caller's geographic and qualityrequirements, and the caller's selection. If the restaurant the callerselected does not have a reservation available for the caller, or thecaller otherwise desires additional service, the caller would initiatethe return-to-operator feature (by, for example, pressing the “*” key)and be reconnected to a Concierge Provider operator. A display wouldappear on the operator's screen of the caller's initial request, all therestaurants which satisfied the caller's geographic and qualityrequirements, all of the caller's previous selections, results of thecaller's attempts to fulfill his/her requests at these establishments,qualifying restaurants which have not yet been tried etc. In this way,when the caller returns to an operator, he/she can immediately be givena choice of all the qualifying restaurants he/she has not yet attemptedto make a reservation at. When the caller ultimately disconnects fromthe call (e.g. goes to an “on-hook” condition), information stored aboutthe concierge request and attempts to fulfill it can either be deletedor stored with the caller's personal profile information (describedbelow) or otherwise for use in serving the caller in the future, reportgeneration etc.

Where real time fulfillment of the concierge request by the operator isdesired, although operator use of an outgoing telephone line to fulfillconcierge requests in real time is relatively straightforward toimplement and provides the features and advantages described above(among others), the preferred manner of providing real time conciergerequest fulfillment is via electronic communication with vendors ortheir intermediaries. This is so because such electronic communicationfacilitates the provision of a number of additional features and a muchsmoother interface with the caller. For example:

In some implementations of such electronic communication, the operatorcan converse with the caller while attempting to fulfill the conciergerequest, so the caller knows what is being done to fulfill his/herrequest as it is happening and is not left in an idle state (e.g. onhold) for a protracted period;

In some implementations of such electronic communication, it is easy totrack requested concierge services, fulfillment attempts etc., as suchrequests are being stored and managed by the Concierge Provider;

In some implementations of such electronic communication, multiplerelated concierge services can be easily fulfilled and tracked as aunit, whereby some requests are automatically tracked or fulfilled basedon the status of other requests (e.g. car service pickup can beautomatically arranged based on scheduled arrival time of a reservedairline flight);

In some implementations of such electronic communication, operator andcaller time is saved by using pertinent previously stored informationrelating to the caller and his/her preferences to fulfill the requestrather than eliciting such information from the caller in real time.

These and other advantages of this aspect of the invention are explainedmore fully below.

Such electronic communication, in a preferred embodiment, is establishedbetween the Concierge Provider and retail on-line reservation systems(ORSs), e.g. World Choice Travel, Expedia.com, OpenTable.com,SavvyDinner, Priceline.com etc. Such electronic communication includesdirect operator access to such systems and/or access to such systems viaa concierge services server. Electronic communication can also beestablished between the Concierge Provider and centralized data andreservation systems (CDRSs) and other types of centralized systems (e.g.Pegasus, Sabre etc.) and/or directly with vendor systems, both of whichcould include direct operator access to such systems and/or access tosuch systems via a concierge services server. It is understood that anycombination of these options is possible and is within the scope of theinstant invention.

Whatever the manner(s) of providing real time concierge service, in apreferred embodiment of the invention, the Concierge Provider will offerboth real time and off-line concierge fulfillment services. One reasonfor this is that real time concierge request fulfillment may consumeconsiderable operator time, which may be a substantial cost to theConcierge Provider which is not built into the cost of the call to theConcierge Provider itself. Therefore, for example, if a vendor or itsintermediaries will not provide a commission to the Concierge Providerfor a referral to the vendor, the Concierge Provider may still provideconcierge services with respect to that establishment as a service toits subscribers, but may offer only off-line concierge requestfulfillment, either because the cost of such off-line fulfillment isless than the cost of real time fulfillment, or because it will motivatevendors who do not offer commissions to change their policies.

Furthermore, it is unlikely that all vendors that Concierge Providersubscribers will wish to patronize will ever all support 24 hour a day/7days a week real time concierge request fulfillment (e.g. they will notsupport an automated interface and will not be open 24 hours a day/7days a week for telephone requests); off-line concierge requestfulfillment should be offered in these circumstances as well.

Direct Operator Access to on-Line Reservation Systems (ORSs)

There are a number of ORSs with existing interfaces to or relationshipswith vendors, including World Choice Travel (hotel, airline and carreservations), Expedia.com (hotel, airline and car reservations),Savvydinner.com (restaurant reservations), Opentable.com (restaurantreservations), Moviephone.com (movie tickets) etc., which offer anon-line user interface for requesting reservations. In one aspect of theinvention, an operator accesses an ORS with the caller still on the linein an attempt to fulfill the caller's concierge request. The operatorwaits to receive confirmation from the ORS that the caller's request hasbeen fulfilled, and information regarding the request (e.g. confirmationinformation, the fact that the request cannot be fulfilled etc.) can begiven to the caller on the telephone (in addition or alternatively togiving the caller this information on the telephone, as described below,such information can be sent to the caller by a variety of means).

Such ORSs may be accessed by Concierge Provider operators just as aconsumer would access them, over the same interfaces provided to thegeneral public. ORSs may, however, customize features and interfaces forthe Concierge Provider. For example:

although some ORSs require entry of credit card information because, forexample, the ORS (or vendor) charges consumers directly for tickets,service fees etc., this requirement could be eliminated for requestsmade through the Concierge Provider. The ORS (or vendor) would bill theConcierge Provider directly for any applicable costs. The ConciergeProvider would in turn bill the subscriber, deduct the applicable costsfrom an account the Concierge Provider maintains on behalf of thesubscriber, or would otherwise be responsible for reconciling the amountowed with the subscriber.

the ORS could permit the Concierge Provider to identify a subscriber bya subscriber identifier (such as the caller's MIN), rather than requirethe operator to enter the name, address, phone number etc. of thesubscriber via the ORS user interface. The ORS would then use thissubscriber identifier to track hotel reservations, car rentalreservations and other concierge service requests made by any suchsubscriber and the status of same. The ORS could also maintain adatabase of subscriber identifiers and information about the subscribersassociated with them (e.g. name, address, phone number, fax number,wireless device number, pager number, Short Message Service deviceinformation, e-mail address etc.) which can be used to bill subscribersdirectly, notify subscribers about concierge request status etc. Thesubscriber identifier can also be used to report information about thesubscriber's concierge requests back to the Concierge Provider, such asinformation which would permit the Concierge Provider to bill thesubscriber for the services used, information which would permit theConcierge Provider to notify subscribers about concierge request status,information from which reports to the subscriber can be generated etc.

the ORS could provide reports to the Concierge Provider (paper reportsand/or on-line accessible reports), such as total activity by service(e.g. number of airline reservations made by the concierge service'ssubscribers, number of car rentals, amounts spent for each, breakdown ofthis information by vendor, number of no-shows, discounts offered andreceived etc.), activity by individual subscriber (e.g. number ofairline reservations made, number of car rentals, amounts spent foreach, breakdown of this information by vendor, number of no-shows,discounts offered and received etc.), activity as broken down bysubscribers of different telephone carriers etc. Such reports can besent to the Concierge Provider in a predefined format at regularintervals (e.g. monthly), and/or the Concierge Provider can request suchreports in any number of ways, such as by sending an identifier of asubscriber to the ORS and receiving (either in real time on the computerdisplay or otherwise, such as batch transmission to the ConciergeProvider) the details and status of all (or any identified subset) ofthe subscriber's concierge requests.

ORSs which provide access to different vendors do not offer thecapability of tracking a “complex transaction,” such as differentinterrelated concierge requests. For example, a car service reservationfor pickup at an airport could be associated with an airlinereservation, both of which could be associated with a hotel reservation,etc. In accordance with one aspect of the instant invention, ORSs wouldprovide support for such complex transactions (either for the ConciergeProvider's benefit or otherwise) by linking the reservations together sothat, for example, if an airline reservation is changed, the associatedcar pickup reservation could trigger a notification to the subscriberasking if the car pickup time should be changed (or the car pickup timecould be changed automatically based on the scheduled arrival time ofthe flight). As another example, if a subscriber requests that theoperator arrange for a car pickup at Portland airport on June 30th at3:00, and then requests a hotel room, the system would set sensibledefault values on the operator's hotel reservation form for thereservation date, time and location.

One way of implementing this capability is by employing reservationcodes (or the like) assigned to reservations, allowing the tracking andinterrelating of these codes across vendors and reservations. Thisfeature also permits reports to be generated by reservation code (i.e.by the complex transactions) so, for example, the concierge servicecould quickly ascertain the details and status of all reservationsassociated with a single complex transaction (in this implementationexample, all reservations associated with the same reservation code). Aswill be appreciated by those of ordinary skill in this art with thebenefit of the instant disclosure, other manners of implementing complextransactions are possible, all of which are within the scope of theinstant invention.

The Concierge Provider may choose to charge vendors for subscribersreferred to them through the ORS. The ORS would keep track of whichsubscribers were referred to which vendors and the status of thesereferrals. The ORS may compensate the Concierge Provider itself(possibly a percentage of the fee the ORS receives from the vendor), orit may forward information regarding these referrals directly to thevendors such that the vendors can pay the Concierge Provider theapplicable fees. These fees can be based on the referral alone, forreferrals that actually patronize the vendors, or on any other agreedupon terms. In addition, the Concierge Provider may itself track thesereferrals and reconcile them with the records of such referralsmaintained by the ORS and/or the payments received for such referrals.

While some ORSs allow consumers to cancel reservations and the likethrough their service (rather than canceling directly with the vendor),they do not actively track reservation status such that consumers canobtain status information about their request from the ORS interface(e.g., a restaurant is closed on a day the consumer has a reservationdue to a snowstorm, or the reserved midsize car is not available but afull size car will be offered at no additional charge, etc.) Inaccordance with one aspect of the instant invention, ORSs would offerthis capability (either for the Concierge Provider's benefit orotherwise) by implementing more sophisticated interfaces to theirvendors and/or CDRSs, interfaces which would allow status to be obtained(by the Concierge Provider and/or the subscriber) by using ORSinterfaces and/or via messages sent by the ORS to the subscriber (or tothe Concierge Provider, which would then notify the subscriber). Themanner for implementing such interfaces would be apparent to one ofskill in the art having the benefit of the present disclosure.

The ORS user interface could be customized to filter outnon-commissionable vendors (i.e. don't give the operator the option touse or refer a subscriber to a vendor which has not agreed to payreferral fees to the Concierge Provider) or to otherwise modify whichvendors can be used based on circumstances. The order in which vendorsare displayed to the operator can also be customized (e.g. display inorder from highest commissions paid to the Concierge Provider to thelowest). Other customizations to the user interface might includecurrency conversion, European style dates, screens in differentlanguages etc. for Concierge Providers that wish to provide service tosubscribers in countries other than the United States.

The ORS could provide a special login to the Concierge Provider to beused for testing and training—a real reservation or other request forservice or product would not be created when it is used.

There are a number of ways the Concierge Provider can identify itself tothe ORS in order to take advantage of these customized capabilities,such as with a predefined, password protected user name. Other methodsor systems by which the Concierge Provider could identify itself to theORS would be apparent to one of skill in the art having the benefit ofthe instant disclosure.

While ORSs may customize capabilities especially for the ConciergeProvider, this aspect of the instant invention is similar to having theoperator access the service on behalf of the caller just as the callerwould access the service for himself/herself. Reliance on this modelalone has disadvantages. For example, the Concierge Provider iscompletely reliant on the ORSs for service, features, tracking,reporting etc. Moreover, if a single caller wants a complex transactionfrom vendors which are not all supported by the same ORS, such as anairline reservation, a rental car and a hotel at the destination and adinner reservation at a restaurant near the hotel, it is difficult tointegrate the requests, made through different ORSs, such that eachrequest is associated with the same order for the same customer and forthe same trip. It is also difficult to integrate the concierge serviceswith other services that may be offered by the Concierge Provider, suchas, for example, information assistance services, personal profile andcalendaring services, etc.

These disadvantages can be overcome, and other advantages achieved, byemploying a concierge server for managing the interfaces to the ORSs andthe Concierge Provider operators. This concierge server can be usedinstead of, or in addition to, the direct operator interface to ORSsjust described.

Concierge Services Server Interface to on-Line Reservation Systems

The concierge server pursuant to one aspect of the invention supportsand manages electronic interfaces between the ORSs and the ConciergeProvider, and interacts with applications for other services offered bythe Concierge Provider to enable integration between the conciergeservice other services offered by the Concierge Provider (including apartially or wholly consolidated user interface for the operator). Theconcierge server can support and provide, alone and/or in conjunctionwith the ORSs, all of the features described above with respect todirect operator access to the ORSs, including the billing, subscriberidentifier, reporting, complex transaction, referral fee tracking,reservation status and non-commisionable vendor filtering features.

Concierge Server Interface to ORSs

A system architecture in accordance with the invention is shown in FIG.9. In a preferred embodiment, concierge server 28 is the same conciergeserver which supports off-line concierge request fulfillment, althoughit is understood that different servers can be used to support real timeand off-line concierge services. Link 610 represents a two waycommunications path between the concierge server and the World ChoiceTravel ORS, link 620 represents a two way communications path betweenthe concierge server and the Open Table ORS, and link 630 represents atwo way communications path between the concierge server and agenerically named ORS-1, which can be any existing or future ORS.Although support of these three ORSs is shown as exemplary, it should beunderstood that the concierge server can support interfaces to anynumber of ORSs. In a preferred embodiment, communications with ORSs arecarried out over extensible mark-up language (XML) interfaces.

As shown in FIG. 9, communications between the concierge server and theORSs are facilitated by a series of “plugin modules.” Each such pluginmodule is responsible for supporting the interface between the conciergeserver and an ORS, including translation between different communicationprotocols (e.g. the concierge server communicates in XML and the ORScommunicates in standard generalized mark-up language (SGML)), dataparameter and validation requirements for communicating with the ORS(e.g. what data should be sent to the ORS to initiate a conciergerequest, how it should be sent, what information the ORS will send tothe concierge server, how it will be sent and what it means, etc.), etc.The plugin can also register itself with the concierge server, which canbe built to automatically permit registration by plugins, whichregistration will include information, for example, about the types ofcapabilities the plugin can accommodate. Programmers of such pluginmodules can be provided with an application programming interface (API)by the Concierge Provider which allows such plugin modules to be writtenwithout any knowledge of the concierge server implementation or theconcierge database schema. This design allows for new ORSs to besupported simply by adding plugin modules to the conciergeserver—modification of concierge server software itself would not berequired to support additional ORSs (or to discontinue support of ORSs).

The concierge server interfaces to the ORSs will substantially eliminatethe need for the ORSs to customize user interfaces for the ConciergeProvider, since the operators will not, pursuant to this aspect of thepresent invention, be utilizing the ORSs' user interfaces (the conciergeserver would provide its own interfaces to the operators). However, theunderlying features and capabilities described with respect to directoperator interaction with ORSs (e.g. the billing, subscriber identifier,reporting, complex transaction, referral fee tracking and conciergerequest status features) would still preferably be supported by the ORSsand/or the concierge server pursuant to this aspect of the presentinvention. For example, with respect to such real time transactions:

although ORSs would not need to customize interfaces to eliminate therequirement that credit card information be entered, the interfacebetween the concierge server and the ORSs could still be built such thatthis information was not sent to the ORSs. The ORS (or vendor) couldstill bill the Concierge Provider directly for any applicable costs, andthe Concierge Provider could still in turn bill the subscriber, deductthe applicable costs from an account the Concierge Provider maintains onbehalf of the subscriber, or would otherwise be responsible forreconciling the amount owed with the subscriber. Some of the informationnecessary for billing the subscriber will be available locally to theconcierge server, since it controls the concierge request information,but some information, such as whether or not the subscriber actuallypatronized the vendor (e.g. showed up pursuant to his/her reservation),would still have to come from the vendor (in this embodiment, via anORS);

the ORS could still permit the Concierge Provider to identify asubscriber by a subscriber identifier (such as the caller's MIN), ratherthan require the Concierge Provider to send the name, address, phonenumber etc. of the subscriber via the ORS user interface with theconcierge request. The uses of the subscriber identifier described abovewith respect to direct operator access to ORSs would also apply to theconcierge server aspect of this invention;

The ORS could still provide the above-described reports to the ConciergeProvider. Again, however, because the concierge server controls theconcierge request information, some of the information necessary togenerate reports will be available locally to the concierge server;

ORSs could still support complex transactions, and the features andcapabilities associated with them, and the concierge server andconcierge database will support such complex transactions as well.

The ORS could still keep track of which subscribers were referred towhich vendors and the status of these referrals, as would the conciergeserver, for the reasons described above.

ORSs could still enhance their interfaces to permit active tracking ofconcierge request status, information which could be sent in batchand/or as requested to the concierge server to allow the ConciergeProvider to apprize their subscribers as to such.

The ORS could still provide a special login to the Concierge Provider tobe used for testing and training, or to check the accuracy ofinformation received over the XML interface, ascertain information notsupplied by the ORS over the XML interface etc.

The ORS will use the communications link to the concierge server toprovide the Concierge Provider with regular batch updates of the vendorsit supports. For example, if a particular ORS handles hotelreservations, the ORS would provide the Concierge Provider with updatesregarding new hotels it supports and/or hotels it no longer supports.The regularity with which these updates are sent by any particular ORSshould be a function of the frequency with which that ORS's informationchanges. This information is stored in the concierge database and, ifthe Concierge Provider also provides information assistance services,such information (or an appropriate subset of it) is sent from theconcierge server to the information assistance application overcommunications link 650 so the information can be stored in DL/Cdatabase server 136.

The information regarding each such vendor in the information assistancedatabase could be flagged, using a “flag field,” to indicate that thislisting represents a vendor that accepts reservations or other conciergerequests from the Concierge Provider. Other fields can be used toindicate other information about the types of services the vendorsupports (e.g. real time concierge requests, changes or modifications,off-line concierge requests, changes or modifications etc.)

Concierge Server Interface to Concierge Database

Link 640 represents a data link over which data is retrieved from orsent to be stored in the concierge database. This database is used tostore reservation information which, in a preferred embodiment, is keyedto the subscribers' MINs. This database can also store references to thedatabases used by other applications, such as the personal profile andcalendaring applications described below. In this way, rather than copyinformation from those other databases into the concierge database, theconcierge database would instead contain references back to the originalsource of information, thereby allowing the concierge application tohave access to the most recent and best data, and substantiallyeliminating the need to synchronize the data in the different databases.

The concierge database is preferably designed in such a way that fieldsspecific to a particular type of concierge activity can be stored in thedatabase without the need to make changes to the actual tables andcolumns of the database themselves. For example, if a new field for carrental reservations that tracked the caller's request for an automaticor a stick shift was added to the concierge database, it should not benecessary to add an “IS_STICK_SHIFT” or similar column to a table in thedatabase. One way to do this is to have the concierge server, during theplugin registration process (during which new plugins can describe tothe server what fields of information are relevant to the ORS itsupports), map the data applicable to the plugin to existing fields inthe database, or automatically create new fields in the database for useby the plugin. Whichever way this is done, it is preferable that manualmodifications to the database to support new plugins not be required.

For purposes of efficient data management, it is preferred thatinformation regarding concierge requests (the request itself, attemptsto fulfill the request, status of the request etc.) be kept in theconcierge database until at least (i) the “end date” of the request haspassed and the request has been successfully fulfilled; or (ii) therequest has been canceled at the subscriber's request, after determiningit cannot be fulfilled and notifying the subscriber, or otherwise. Oncethe request has passed one of these two criteria, it would be flagged as“closed.” Concierge requests that are part of a complex transaction,such as a multi-reservation itinerary, should not be considered closeduntil all the requests which make up the transaction (e.g. all thereservation requests in the multi-reservation itinerary) are closed. Theamount of time after a request is closed that the information related toit is retained can be determined based on the type of request (e.g.information regarding requests for hotel reservations are kept for 5days after the requests are closed, whereas requests for car rentalreservations are kept for 3 days after the requests are closed), as afunction of who the subscriber is (e.g. the subscriber can indicate inhis/her personal profile that information regarding his/her requests areto be kept until the end of the month in which they are closed, afterwhich a summary report is to be sent to him/her, and/or subscribers canpay to have information regarding their requests kept longer than thedefault time), or otherwise.

In a preferred embodiment, the concierge server supports the ability toreplicate the information in the concierge database to a second database(not shown). Any time a record is created or modified, it would bereplicated to a second off-line database. This replication of data canbe implemented either within the concierge server or by using a databasereplication tool such as Quest Shareplex. The off-line database could beused for generating reports (without impacting the real time system) andfor storing information related to closed concierge requests for longerthan they are stored on the on-line database. The period of timeinformation is retained on the off-line database can also be determinedbased on the type of request, who the subscriber is, or otherwise. Theoff-line database could also be used to store information used only togenerate reports, information such as ORS response times, bandwidthusage etc. which will not be accessed in real time.

Concierge Server Interface to Information Assistance Application

Link 650 provides a two way communications, preferably in XML, betweenthe concierge server and an information assistance application (“DAApplication”), such as that which would be employed by a ConciergeProvider which also offers information assistance services. The DAApplication provides, controls and manages the provision of informationassistance services, such as information assistance user interfacescreens, communications with directory listings databases etc. Interface650 facilitates the integration of concierge services with informationassistance services.

Although, as described above, in some aspects of the invention theconcierge server itself can provide user interfaces to operators (theoperators of a Concierge Provider which is not also an informationassistance provider is not shown in FIG. 8), when the Concierge Provideris also an information assistance provider, the DA Application mayprovide an integrated interface to both the information assistance andconcierge systems. Alternatively, a hybrid system can be used, whereby,for example, the DA Application provides a separate user interfacescreen or screens with fields for concierge request information, wherebyselected fields on the concierge screen can be automatically populatedfrom fields on the information assistance user interface screen. In thislatter example, it is the information on the separate conciergescreen(s) that are submitted to the concierge server to initiate aconcierge request.

In one scenario, when an information assistance request is received byan information assistance operator, the operator will search theinformation assistance database for information responsive to thecaller's information assistance request. For example, a customer may askfor the telephone number of The Beach House Restaurant in Cardiff By TheSea, CA, and the operator will do a search for that number. If anindication had been previously received from an ORS that it can supportreal time reservations at The Beach House Restaurant, the DA Applicationwill recognize this fact (e.g. from the flag field stored in thedatabase) and display information to the operator that this vendoraccepts real time concierge requests from the Concierge Provider (suchas by highlighting the entries for this vendor on the operator's screenand/or providing a textual notification such as “this hotel takesreservations”.) The operator could then offer to make the reservation atThe Beach House Restaurant for the caller while the caller waits.

As an alternative to selecting a hotel, car rental agency, restaurant orother vendor by selecting from a list of all vendors satisfying thecaller's requirements (whether or not they accept real timereservations), the operator can also, by typing appropriate keywords orotherwise, directly initiate a search for vendors at which the ConciergeProvider can make real time reservations for the caller. For example,the operator could enter “City-Portland, Name=Hilton” and a designatedkey or keys (such as “CTRL R” for listings of vendors which takeReservations) to initiate the search, and all matching Hilton hotels inPortland that support real time reservations from the Concierge Providerwould be displayed.

As described, in a preferred embodiment, the information assistanceoperator would resolve which establishment the subscriber was interestedin, and would then initiate a concierge request with respect to thatestablishment. However, it can be possible for the operator to simplyforward a broad concierge request to the concierge server, such as arequest by a subscriber to “make me a reservation for tonight at aHilton in Portland, Oreg.” The concierge server would then attempt tofulfill the request, and report the results of the attempt back to theDA Application, including, if applicable, the name, address etc. of theHilton in Portland at which the reservation was made.

It is possible that there will be some delay between the time theoperator initiates the concierge request and the time either aconfirmation or an indication that the request could not be fulfilled isreceived by the operator. Therefore, the concierge server shouldimmediately return an interim message (and possibly subsequent interimmessages) to the DA Application for display to the operator, such as“please wait” or “still processing,” so that the operator knows theconcierge request has been received and is being processed.

However the request for concierge services is initiated, the requestmust be sent from the DA Application to the concierge server overcommunications link 650. The DA Application will send the conciergeserver information about the concierge request, the ORS which servicesthe vendor at which the concierge service is requested (the ORS whichincluded this vendor in the batch updates stored in the informationassistance database), and any vendor identifier supplied by the ORS forthat vendor. This information will assist in ensuring that there is amatch between the information assistance listing for the vendor and theORS listing for the vendor, even though the listing name may not beexactly the same for both.

Preferably, the batch information received from the ORSs will includewhich vendors support real time concierge request fulfillment and whichsupport off-line concierge request fulfillment, and for each vendor,which types of concierge requests can be canceled or modified in realtime and which types the ORS must confirm with the vendor sometime later(for example, using the World Choice Travel ORS, it is presentlypossible to cancel a car rental reservation, but confirmation of thiswon't be received for up to 48 hours.) The operator would then have thisinformation available to him/her at the time he/she takes the conciergerequest from the caller, and would know before he/she initiates arequest (or a request for a change or cancellation of such a previouslymade request) that the vendor in question supports the type of requestin question. The concierge server would also know a priori which ORSscan support which requests, and will therefore not have to determinethis in real time. If an ORS does not provide this information to theconcierge server in batch form, the concierge server can determine theORS's capabilities in real time, either by specifically communicatingwith the ORS to determine its capabilities or by simply submitting therequest to the ORS and receiving notification back from the ORS that therequest cannot be fulfilled if the ORS does not support the type ofrequest in question.

If a subscriber desires a real time transaction, and a real timetransaction is not supported by any qualifying vendor which can fulfillthe request, the caller can be offered the option of having the requestfulfilled by the Concierge Provider off-line. Whether the request is aconcierge request, a change request or a cancellation request, theconcierge server should support the ability to regularly “poll” the ORSto determine the status of the concierge request or if thechange/cancellation has been processed. Once the concierge serverreceives a confirmation from the ORS that the concierge, change orcancellation request has gone through, or any other status informationfrom the ORS, the concierge server can initiate delivery of thisinformation to the subscriber, possibly by the means described in thesubscriber's personal profile.

Change and cancellation request can give rise to concierge requestdiscrepancies. For example, the subscriber may have made a car rentalreservation (and had this confirmed), and then some time later, callback and request that the date of the pickup be changed from June 30thto June 29th. However, the ORS may not support a real time change ofthis type of reservation, but instead may only allow the change requestto be submitted and a confirmation of the change returned back somehours (or even days) later. In this type of scenario, the conciergeserver must be capable of keeping track of these changes to thereservation in its local database, even though this change hasn't yetbeen confirmed by the ORS. This will allow the Concierge Provider toretrieve the correct (from the subscriber's perspective) reservationdetails, put the reservation date in the correct location on thesubscriber's personal calendar (as described below), etc. Of course, ifthe ORS does not support electronic changes to concierge requests, thesechange requests must be flagged for “manual fulfillment,” whereby anoperator or fulfillment agent (which may be the same person) can takethe appropriate steps to accommodate the subscriber's request (e.g. callthe car rental agency directly).

When the concierge server has received a confirmation from an ORS thatthe requested concierge request has been fulfilled, it will send thisinformation, along with any appropriate confirmation information (e.g.confirmation number, name of the vendor at which a reservation was madeand the time, etc.), over communications link 650 to the DA Application,which will display this information to the operator. The confirmationinformation would then be given to the caller over the phone and/orprovided to whichever persons, by whatever means, the caller specifies,either in real time or as defined in the caller's personal profile.

Alternatively, the concierge server may determine that the conciergerequest cannot be fulfilled. In this event, an appropriate message wouldbe sent from the concierge server to the DA Application, which wouldthen display a message for the operator on the operator screen. Thisinformation, too, would then be given to the caller over the phoneand/or provided to whichever persons, by whatever means, the callerspecifies, either in real time or as defined in the callers' personalprofile information.

Concierge Server Interface to Other Concierge Provider Applications

As shown in FIG. 9, the concierge server can also interface withapplications for other services that may be offered by the ConciergeProvider in order to integrate these services with the conciergeservices. Of course, these services can also be integrated withinformation assistance services, and the information assistance operatorcan offer information assistance, concierge services and other servicesall in an integrated fashion.

Link 660 represents a two way communications path, preferably an XMLinterface, between the concierge server and a subscriber calendarapplication which maintains subscribers' calendars, and link 670represents a two way communications path, also preferably an XMLinterface, between the concierge server and a subscriber's personalprofile information. Like the interfaces to the ORSs, the interfaces toapplications are also preferably made through plugins, so that theconcierge server can support new applications (and support can bediscontinued for applications) without requiring modifications to theconcierge server itself. The calendaring and personal profile features,which are described in copending, commonly assigned application Ser. No.09/865,230, filed on May 25, 2001, hereby incorporated by reference, canbe integrated with the concierge capabilities such that, for example,the caller can indicate preferences and other information which will bestored by the Concierge Provider and used to facilitate the taking andfulfilling of concierge requests. This could include (but is not limitedto) information relating to:

Subscriber General Information

Subscriber credit card information (names, numbers, expiration datesetc. for each card and a default card to be used if more than one cardis defined), subscriber contact information (e.g. address, phone number,fax number, wireless device number, pager number, Short Message Servicedevice information, e-mail address etc.), contact information forfriends, relatives, acquaintances and others (e.g. name, spouse's name,address, phone number, fax number, wireless device number, pager number,Short Message Service device information, e-mail address etc.), whetherreservation information should automatically be added to thesubscriber's calendar (see description of calendar capability below),etc.

Restaurants

Information contained in the caller's profile could include, forexample, preferred types of food (e.g. Italian, Chinese), preferredrestaurants, preferred restaurants for each different type of food(e.g., Giambellis for Italian food, Shun Lee Palace for Chinese foodetc.), preferred restaurants by city, preferred seating (e.g. smoking ornon-smoking), review requirements (e.g. the caller may be interestedonly in restaurants with a food rating over “20” in the Zaggat guide),preferred seating time, accepted credit card requirements, preferrednumber in party, preferred seating time, preferred price range, childseat requirements etc.

In this way, a caller can access the Concierge Provider from anywhere inthe country, and by indicating only, for example, that he/she wants adinner reservation, have the Concierge Provider make recommendations andreservations, either in real time or after the caller hangs up.

Movie Theaters

Information contained in the caller's profile would include, forexample, preferred movie theaters, preferred types of movies (e.g.comedies, romance, action drama, musical etc), favorite actors and otherinformation which would allow the Concierge Provider not only to makereservations but to suggest movies the caller might like to see. Similarcriteria would apply to live theater preferences.

Car Rental

Information contained in the caller's profile would include, forexample, preferred car rental agencies (e.g. Hertz, Avis, Budget etc.),preferred car type (e.g. compact, mid-size, SUV, pick-up, transmissiontype etc.), preferred options (GPS system, unlimited mileage, insurancerequirements, gas purchase options), frequent flier number (or othersimilar number whereby the customer gets miles, rebates etc. forfrequent travel or use), ability to pick up and drop off at differentlocations, preferred price range, child seat requirements etc.

Airlines

Information contained in the caller's profile would include, forexample, preferred airlines, preferred seating (window or isle),frequent flier number (or other similar number whereby the customer getsmiles, rebates etc. for frequent travel or use) etc.

Hotels

Information contained in the caller's profile would include, forexample, preferred hotels (e.g. Hilton, Holiday Inn etc), preferred roomtype, smoking or non-smoking preference, preferred floors (e.g. highfloors preferred), preferred bed type (e.g. king, queen, twin etc.),preferred number of beds, amenity requirements (pool, health club, 24hour room service, child services, bar, restaurant, room service,business center, golf, tennis, free parking, valet parking, freenewspaper, handicap accommodations, laundry services, pet friendly,skiing, shoe shine etc.), preferred price range, credit cards accepted,child seat and crib requirements etc.

It will be apparent to those skilled in the art having the benefit ofthe instant disclosure that this aspect of the present invention appliesequally to many other reservation and ticket oriented domains (e.g.sporting events, trains etc.), and the scope of this invention isintended to be broad enough to cover each of these domains. Moreover, itwill also be immediately apparent which preferences make sense for eachtype of domain (e.g. preferred carrier would apply to trains, frequentflier numbers would apply to hotels etc.).

With this information having been previously stored by the system, theoperator does not have to elicit the information from the subscriber asthe subscriber's concierge request is being taken, thereby saving bothoperator and subscriber time. Because the system can identify the callerfrom the caller's MIN, before the caller actually begins to speak to theConcierge Provider operator, the operator will already know who thecaller is, and will have access to all the stored information about thecaller. The subscriber can even identify in his/her personal profileinformation what types of calls he/she will generally make, and whattype of information about him/her he/she would like on the operator'sscreen before he/she and the operator even begin to speak. If the callerdoes not subscribe to the Concierge Provider's personal profile orcalendaring services, the caller will have to repeat his/her preferenceinformation, availability and the like on every call. This gives theoperator the opportunity to cross sell other services on such calls bysaying, for example, “would you like us to store this information foryou so I don't have to ask you these questions on future calls.”

Of course, a caller should have the option on any call to overridehis/her personal preferences, to add to them and/or to describepreferences which apply to the instant call only. For example, althoughthe caller may identify in his/her personal profile that he/she is to becontacted by e-mail if a reservation is confirmed (e-mail which caninclude, for example, name, number, address, driving directions etc. ofthe establishment at which the reservation is made) or by phone if itcannot be fulfilled, he/she can change these requirements on anyspecific call with respect to any specific concierge request. As anotherexample, although the subscriber may have identified in his/her personalprofile that confirmation about dinner reservations be provided to allattendees, the subscriber may not have stored information about some ofthe attendees in his/her personal profile. This information too wouldhave to be provided by the caller during the call.

As explained above, the subscriber can identify that driving directionsbe sent to himself/herself and/or others, and the manner in which thosedirections are to be sent. Moreover, because this invention provides forreal-time reservation confirmation, it is possible, for example, that acaller will be in a car at the time the reservation is confirmed andwill want to travel immediately to the establishment at which thereservation was made. Therefore, in a preferred embodiment of theinvention, the concierge server also provides via link 680 a drivingdirections application, such as that described in copendingcommonly-assigned application Ser. No. 09/826,122, filed on Apr. 4,2001, which is incorporated herein by reference. The driving directionsmay be communicated in XML.

Because the Concierge Provider will also keep the subscriber's calendar,and the concierge server will have access to this calendaringinformation over link 660, the Concierge Provider can act as thesubscriber's personal assistant. Not only can the operator take andfulfill concierge requests for the caller, the operator can tell thecaller when he/she is available, when other subscribers to thecalendaring service are available (if those subscribers permit suchdisclosure either in general or to the requesting subscriber inparticular) and, when concierge requests are fulfilled, the subscriber'scalendar can be automatically updated. Subscribers to the calendarservice can indicate in their personal profile who can have access totheir calendar information. Calendar information can also be sent to thesubscriber via electronic means so that, for example, it can besynchronized with the subscriber's other electronic calendars (MicrosoftOutlook, Palm Pilot, etc.)

[While the discussion thus far has been described in the context ofsubscribers issuing concierge requests over the telephone to theConcierge Provider, it is also possible, of course, for conciergerequests and other services to be requested by the subscriber by othermeans. For example, subscribers can be given e-mail addresses to whichto submit their concierge or other requests for service, and thesee-mail requests can be serviced by either operators dedicated toservicing such requests or by the same operators that servicetelephone-initiated requests. As another example, the Concierge Providermay provide a web-based interface by which subscribers can log on andmake their concierge service requests.

Concierge Provider Interfaces to CDRSs

As shown in FIG. 9, some ORSs, such as World Choice Travel (WCT), do notinterface directly to vendors, but rather interface to CDRSs, which arecentralized management systems supporting one or more vendors. Forexample, the Sabre CDRS manages reservation and scheduling informationfor a number of airlines, airlines which themselves use Sabre as theirown data management system. CDRSs generally provide interfaces to ORSsand others for a fee.

CDRSs can be thought of as a special kind of ORS and, as shown by links690, 700 and 710, the concierge server can interface with CDRSs inaddition to or instead of interfacing to ORSs. Link 690 represents a twoway communications interface with the Sabre CDRS, link 700 represents atwo way communications interface with the Pegasus CDRS, and link 710represents a two way communications path between the concierge serverand a generically named CDRS-1, which can be any existing or futureCDRS. Although support of these three CDRSs is shown as exemplary, itshould be understood that the concierge server can support interfaces toany number of CDRSs. In a preferred embodiment, communications withCDRSs are carried out in XML.

As will be appreciated by one ordinary skill in the art having thebenefit of the present disclosure, the nature of these interfaces, thefeatures they would provide and the requirements on both the ConciergeProvider, the concierge server and/or the CDRSs to provide thesefeatures are substantially the same as those described above withrespect to interfaces (both direct operator access and concierge serverinterfaces) to ORSs, and any necessary modifications would be apparentto those with ordinary skill in the art.

Concierge Provider Interfaces Directly to Vendors

Links 720, 730 and 740 provide two way communications, e.g., in XML,directly between the concierge server and vendors which, in a preferredembodiment. Because there are likely to be vendors which would like tosupport real time transactions but for which there is no supporting ORSor CDRS, it may be preferable in some circumstances to provide fordirect electronic communication between the Concierge Provider and oneor more vendors. Although direct electronic communication links withthree vendors is depicted in FIG. 9 as exemplary, it should beunderstood that the concierge server can support interfaces to anynumber of vendors. It will be appreciated by one of ordinary skill inthe art having the benefit of the present disclosure that the nature ofthese interfaces, the features they would provide and the requirementson both the Concierge Provider, the concierge server and/or the vendorsto provide these features are substantially the same as those describedabove with respect to interfaces (both direct operator access andconcierge server interfaces) to ORSs, and any necessary modificationswould be apparent to those with ordinary skill in the art.

It will be appreciated that the instant invention extends well beyondmaking reservations, reserving tickets and the like. The access tovendors and/or their intermediaries provided by the concierge serverallows a host of other concierge services to be offered to subscribers.For example:

1) customers can keep in their personal profiles the types of specialsthey would like to be notified about (e.g. sales on Levi's jeans,Tropicana orange juice etc.), the concierge server can receiveinformation regarding such sales over the above described interfaces(either directly from vendors or their intermediaries or by pollingthem) and the information passed on to the subscriber;2) the subscriber can keep in his/her profile information about thetypes of television shows he/she likes to watch (e.g. favorite shows,favorite actors, favorite sports teams etc.). He/she can then simplycall the concierge service and ask “what's on TV tonight,” and, with theaid of a Concierge Provider interface to a TV Guide type system, be toldabout television shows he/she might like to watch;3) the Concierge Provider can offer subscribers price comparisons ofsimilar goods at different stores, notifying the subscriber when adesired event is taking place (e.g. Michael Jordan coming to MadisonSquare Garden to play the Knicks, the Bolshoi ballet in town, theSuperbowl is on TV etc.);4) the Concierge Provider can purchase items for the consumer, either ona single demand basis (e.g. a Sony 32 inch Sony WEGA television forunder $400) or on regular intervals as defined by the subscriber (e.g.sending flowers to the subscriber's wife on their anniversary everyyear, the date of which is maintained in the subscriber's calendar).

Concierge-Type Service Example

By way of example, the concierge-type service will now be described withthe aid of FIGS. 10 and 11. As mentioned before, the concierge-typeservice may be an information assistance service provided in step 1006of FIG. 1. In this example, the caller is at John F. Kennedy airport inNew York calling a friend (called party) in San Diego using the enhancedtelecom service. While the caller and called party on a phoneconversation, the caller suggests to have dinner with the called partyat a vegetarian restaurant in “Cardiff by the Sea” near San Diego.Taking advantage of the enhanced telecom service feature which allowseither the caller or called party to invoke information assistanceduring a call, the caller in this instance presses a predeterminedtelephone key to invoke information assistance. In a manner describedbefore, an operator is conferenced in to the call to provide thenecessary information assistance which includes in this instance aconcierge-type service. It should be appreciated however, that arestaurant reservation service is but one type of service that theconcierge-type service may be able to provide. Other areas of use mayinclude, but are not limited to: information, reservation and ticketingfor events, accommodation, transportation and travel, informationregarding news, stock prices and weather, and providing access to otherservices such as grocery or flower delivery, etc.

Continuing the above example, the caller can either request directorylisting information (step 210) or directly make a reservation request(step 208). If the caller requests restaurant listing information atstep 210 the operator prompts the caller (step 211) for detailsregarding for example the type of restaurant, the restaurant location,the approximate date and time of the reservation and other preferenceslike for example dietary requirements, smoking or non-smoking, outdoorsor indoors etc. The operator then inputs these details into a callerprofile database through server 134 (step 212). Using a search engine,the operator searches a directory listing database through server 136(step 213) for restaurants based on the above-mentioned caller detailsand preferences. As per our example, a suitable restaurant is located in“Cardiff by the Sea,” near San Diego.

If the caller knew the name of the restaurant he/she wanted he/she maymake a specific reservation request (step 208) directly on connection tothe operator. In such a case or as per our example, the operator thenprompts the caller for reservation details (step 214) such as therestaurant name (if the operator did not locate it, supra), the caller'sname, a second choice of restaurant, a required reservation date andtime, alternative times, contact details and any additional preferencessuch as smoking or non-smoking, type of credit card to be used,restaurant views, etc. These details are input into a browser typegraphical user interface (GUI) as shown in FIG. 4. The reservationdetails are then stored in the caller profile database along with areservation request or ticket while the caller is on hold (step 215).Based on the request, concierge server 28 at step 216 determines whetherthe request can be fulfilled in real time through an ORS describedabove. If positive, server 28 at step 217 attempts to fulfil the requeston-line. At step 218 server 28 determines whether the real-timeattempt(s) failed. If negative, at step 219 server 28 informs (e.g.,textually) the operator of the reservation made thereby, who in turninforms (e.g., verbally) the caller on hold of the same, and then eitherprovides the caller with further assistance or disconnects from theconnection between the caller and called party (step 236).

Otherwise, if the request cannot be fulfilled in real time, the ticketis automatically forwarded to a fulfillment agent (FA) for processingoff-line (step 220). The operator then informs the caller that thereservation request is being processed off-line, and either provides thecaller with further assistance or disconnects from the connectionbetween the caller and called party (step 236).

It should be noted that the operator may also process the tickethimself/herself. By default, the ticket is automatically forwarded to afulfillment agent at the directory assistance center where the call wasreceived, in our example New York. The operator, fulfillment agent or anautomated system at the directory assistance center will then forwardthe request to the directory assistance center nearest the requestedvenue. In the illustrative example the request will be forwarded to theSan Diego directory assistance center. The fulfillment agent in SanDiego thus automatically receives the reservation request (step 221),shown by the graphical user interface in FIGS. 4-8.

The fulfillment agent then attempts to contact the restaurant (step222). Should the fulfillment agent be able to contact the restauranthe/she will attempt to make a reservation (step 223). The fulfillmentagent then updates the status of the ticket (step 224) on the systemirrespective of whether he/she was, in fact, successful in making thereservation or not, indicating last action performed, result,reservation details etc. (as seen in FIGS. 6 through 8). After eachchange of status the fulfillment agent or the system automatically setsa next action time for his/her attention sometime in the future. Therequest then slots into the appropriate place in a fulfillment queue.The fulfillment agent cannot set nonsensical time periods like zerominutes or two years. New tickets are prioritized so as to be dealt within a timely manner on a first-in-first-out basis. After a set amount ofunsuccessful tries, the fulfillment agent is automatically prompted totry the second restaurant choice.

After a set amount of time, say for example thirty minutes, thefulfillment agent retrieves the status of the request (step 228) andcontacts the caller informing him/her of the status of his/her request(step 230). The fulfillment agent may contact the caller by phone, fax,email or pager. The caller may also call the service back before thecaller is contacted by the fulfillment agent (step 226). The reservationstatus is retrieved from the system (step 228) and the caller isinformed of the current status of the reservation request (step 230). Ifrequired, the operator or fulfillment agent may modify the reservationrequest (step 232) which is automatically reforwarded to the fulfillmentagent (step 218). Once the reservation is made or the caller indicates adesire to cancel the request, the operator or fulfillment agent closesthe Ticket and provides the caller with further assistance ordisconnects the caller from the system (step 236).

An important feature of the present invention is an activity loggingfunction (step 234). All caller requests are logged in caller profiledatabase server 134 in FIG. 2. The activity log helps with internalauditing and billing of that particular caller. On-demand printedreservation status reports may be provided to call center managersand/or supervisors. Furthermore when the caller makes use of theconcierge service, his/her mobile identification number (MIN), callerdetails, most frequent requests and past request activity isautomatically presented to the operator. The caller therefore will nothave to resupply repetitive details to the operator, thus speeding upthe process and reducing the operator's processing time. A fulfillmentagent such as a supervisor who is not currently active, then handles anyconcierge requests that are active or open at that particularinformation assistance center.

The system may generate reports such as the number of calls processed bya particular center or by the system as a whole. Other reports mayinclude reports indicating the average time spent on each ticket, thetime spent fulfilling a ticket request and the time taken to contact acustomer.

The telephonic concierge system may be affected by other scenarios suchas: the fulfillment agent may be unsuccessful in contacting therestaurant; the requested reservation time may be unavailable; thecaller might cancel the request; the caller may request a change in thereservation time while still pending.

Voicemail Direct Placement

As discussed above, there are a number of circumstances, in both theoff-line and real time concierge fulfillment embodiments of the presentinvention, when it will be necessary or desirable for the ConciergeProvider to provide the subscriber with information after the subscriberhas placed his/her concierge request. For example, in the off-lineembodiment, it is necessary to advise the subscriber of the results ofthe Concierge Provider's attempt to fulfill the subscriber's conciergerequest and information associated with the request (e.g. name and otherinformation regarding the establishment at which the request wasfulfilled, confirmation number, driving directions etc.) In the realtime embodiment, for example, the Concierge Provider will confirmconcierge requests which for whatever reason could not be confirmed inreal time (or to advise the subscriber that the concierge request couldnot be fulfilled), as well as provide other information as describedabove (e.g. name and other information regarding the establishment atwhich the request was fulfilled, confirmation number, drivingdirections, etc.)

In addition to the various ways described above by which the ConciergeProvider can contact the subscriber (mail, phone, fax, wireless device,pager, SMS device, e-mail/Internet etc.), there are circumstances whenit is desirable to record a voice message for the subscriber. Forexample, because of the virtually universal proliferation of telephones,voice messages can be accessed from virtually any place, at any time,and do not require the subscriber to have or to be near any of his/herown communications devices in order to retrieve such messages. Moreover,there are some types of information that the subscriber may prefer toreceive in the form of a recorded voice message.

In this illustrative embodiment, the enhanced telecom service providerestablishes for each of its subscribers, as part of an initial serviceregistration, a voice mailbox on a voice mail system maintained by theservice provider. A recording of the voice message can be made at theConcierge Provider (by the fulfillment agent, an information assistanceoperator if said Concierge Provider is also an information assistanceprovider, or otherwise), and sent via virtual network 1100 in FIG. 12(such as the Internet, a packet switched network, a virtual privatenetwork or a software defined network, etc.) to voice mail system 1110.An identifier would be sent along with the message, such as thesubscriber's MIN or ANI, which will identify the subscriber and therebythe voice mailbox into which the message should be placed. The messagemay be transmitted to voice mail system 1110 in the form of a sound filesuch as a WAV file, MP3 file, etc.

It is understood that voice mail direct placement can be used insteadof, or in addition to, any of the other methods of contactingsubscribers (or others) described above. In one embodiment of thisaspect of the present invention however, contact by voice mail directplacement is offered to all subscribers, whereas preferred subscribersare also (or alternatively) called by the Concierge Provider to assurereceipt of the information, and to allow the caller to speak to a humanat no additional charge who can answer any questions.

Additional Features

The system and method of the present invention has been described.Clearly, there are still other alternatives and equivalents that arewithin the spirit and intent of the invention and will occur to a personskilled in the art. For example, without limitation, the system mayprovide the caller with automated delivery of recorded and/ortext-to-speech notification of status of the reservation, with scheduleof attempts followed until confirmation of receipt is received. Thecaller may be able to make periodic requests, such as for example thesame restaurant reservation on the first Monday of each month. Thecaller may request a group notification, to inform a group of people ofthe reservation confirmation details. The caller may make a “type”request where for example all restaurants of a particular type arecontacted, from the nearest to the farthest until the request can befulfilled. The caller may make a group negotiation by making a groupreservation and getting consensus from all parties.

Data extracted from the system may be used for internal reports. Suchreports may indicate system usage information or service (a particularrestaurant hotel, airline) usage information. This information mayinclude the most popular service requests, for example the most popularrestaurants, and may be used to make recommendations. The data may alsobe utilized for other purposes such as marketing or market research.

Vendor Selection Criteria Conflict Resolution

In accordance with an aspect of the invention, when a subscriber makes arequest for service without identifying specifically which vendor he/shewould like to patronize, the present invention allows a vendor to beselected for the subscriber based on a broad set of diverse criteria.Examples of criteria which can be used by the Concierge Provider toselect a vendor include:

1) The subscriber's preferred vendor(s) and other preferences of thesubscriber, such as characteristics of vendors he/she likes topatronize, preferred service options, his preferred locations forrequest fulfillment, etc., as defined in the subscriber profile;2) The Concierge Provider's preferred vendors. As described above, forexample, a Concierge Provider may prefer vendors which will paycommissions to the Concierge Provider. It will be understood by those ofskill in the art having the benefit of the instant disclosure that, inthose embodiments of the instant invention in which a telephone carrierroutes concierge request calls from its own subscribers to the ConciergeProvider for fulfillment, the telephone carrier may itself havepreferred vendors. (It should be noted that the term “telephone carrier”here is interchangeable with the “enhanced telecom service provider”especially when the function of the telephone carrier is absorbed intothat of the enhanced “telecom service provider” as described before.)The telephone carrier's preferences can also be taken into account whenselecting a vendor for one of its subscriber's requests;3) Which vendor(s) can supply the goods or services desired bysubscribers at the lowest cost;4) Which vendors are closest to the subscriber's present geographiclocation (which can be determined using GPS technology, by interactionwith the subscriber, or otherwise).

Furthermore, while some subscribers will want to fulfill their ownconcierge requests, and will simply want to be connected to the chosenvendor by the Concierge Provider (a scenario more likely to happen whenthe Concierge Provider comprises an information assistance provider),other subscribers will want the Concierge Provider to fulfill therequests for them. As discussed above, some vendors will supportinterfaces for electronic real time request fulfillment while otherswill not. Therefore, subscriber, Concierge Provider or telephone carrierpreferred vendors can also be a function of the support-provided byvendors for electronic request fulfillment.

Because such broad and diverse criteria are factored into the vendorselection process, there will be times when one or more selectioncriteria will conflict. For example, a subscriber may define in his/herprofile that his/her preferred towing company is King's Towing, but theConcierge Provider may prefer Queen's Towing because that company paysthe highest commissions. Or, the subscriber may request a dinnerreservation at a restaurant near his/her present geographic location.After a GPS system (e.g., a GPS receiver incorporated in thesubscribers' telephone) is utilized in a well known manner to determinethe subscriber's present location, it may be determined that thetelephone carrier's profile indicates that the subscriber does not havepermission to have concierge requests fulfilled in that area. These areconflicts that the Concierge Provider must resolve before proceedingwith attempts to fulfill the subscriber's concierge request.

In addition to conflicts between a subscriber's preferences and thepreferences of one of his/her service providers, conflicts can alsoexist between preferences defined in a profile associated with a groupto which the subscriber belongs and the subscriber's own personalprofile. Indeed, even a subscriber's own vendor selection criteria maybe inconsistent. For example, a subscriber's preferred restaurant maynot accept his/her preferred credit card, or a subscriber's preferredcar rental agency may not have cars available with the subscriber'spreferred options.

Such conflicts can also arise in instances where the subscriber doesidentify specifically which vendor he/she wants to patronize. Forexample, the subscriber may specifically request a reservation at Tavernon the Green restaurant, but a profile for a group to which thesubscriber belongs may indicate that the subscriber may not makereservations at a class of restaurants to which Tavern on the Greenbelongs (e.g., the group profile represents a company profile wherebythe company would be billed directly for the cost of the meal, andTavern on the Green belongs to a defined class of restaurants which aretoo expensive).

One method for resolving such conflicts, of course, is to simply notifythe subscriber each time such a conflict arises and ask him/her forfurther instructions. While this method is within the scope of theinstant invention, it is not preferred. If a subscriber has notidentified a vendor at the time he/she places his/her concierge request,for example, he/she is presumably flexible as to the vendor, and mightprefer that a vendor simply be selected for him/her, even if it is nothis/her preferred vendor. Moreover, subscribers will likely not want tobe bothered every time one of their preferences cannot be satisfied,irrespective of how important or unimportant the preference is to them.

Therefore, in accordance with a preferred embodiment of the instantinvention, a conflict resolution algorithm (“CRA”) is employed toresolve conflicts between vendor selection criteria. One example of themanner in which such CRAs are employed in the instant invention isdescribed with respect to FIG. 13.

In step 400, a subscriber calls a Concierge Provider seeking fulfillmentof a concierge request, and conveys information pertaining to therequest to a Concierge Provider agent. In step 402, stored preferencesprofiles pertaining to the subscriber are identified. These wouldinclude, for example, the subscriber's personal profile, as well as anyprofiles associated with any groups the subscriber is a member of, anyprofiles defining preferences of the Concierge Provider, any profilesdefining preferences of the subscriber's telephone carrier, etc.

In step 404, the agent listens to the subscriber's concierge request andenters it into the system, and in step 406, it is determined whether anyconflicts exist between the subscriber's request and/or preferences andany conflicting instructions or other criteria the Concierge Providermight be operating under. While, in a preferred embodiment, the presenceof such conflicts is identified automatically by the system after theagent enters the concierge request, it will be appreciated that theagent could be provided with information (either on his monitor orotherwise) which he could visually inspect for conflicts. Such visualinspection for conflicts is within the scope of the instant invention.

If it is determined in step 406 that no conflicts exist, the systemproceeds to attempt to fulfill the concierge request in step 408, suchas, for example, by proceeding to step 216 in FIG. 10.

If it is determined in step 406 that one or more conflicts does exist,the Concierge Provider proceeds to determine, in step 410, if thesubscriber's concierge request included identification of a specificvendor, such as a specific restaurant, at which he/she would likehis/her concierge request fulfilled, and whether it was thatspecifically identified vendor which caused the conflict. If the answeris yes, it is presumed that fulfillment of the request with thespecifically identified vendor is critical to successful completion ofthe concierge request, and therefore the subscriber is notified of theconflict at step 412. It is likely the subscriber will then eitherchange his concierge request or indicate that he does not desirefulfillment of an alternative request.

If the subscriber's concierge request did not include identification ofa vendor at which he would like his concierge request fulfilled, a CRAis accessed in step 414 to attempt to resolve the conflict. In apreferred embodiment, the CRA is stored in association with thesubscriber's personal profile, since the CRA for each subscriber can bedifferent (e.g., the CEO of a company may have a CRA which indicatesthat his personal profile takes priority over the company's groupprofile, whereas this would not be true for the rank and fileemployees). Of course, the same CRA can also be used for a predefinedgroup of subscribers, with that group CRA itself defining differencesbetween how individual members of the group are to be treated. Thoseskilled in the art having the benefit of the instant disclosure willrecognize that CRAs can be stored in any manner in which they can bereadily retrieved, and that a CRA applicable to all subscribers can beutilized in addition to or instead of subscriber or group-specific CRAs.

One example of a CRA is shown in FIG. 14. In this example, the CRA isimplemented as a static definition of priorities, that is, whichcriterion takes precedence over which. As shown, the priorities aredivided into “External Priorities” and “Internal Priorities.” Externalpriorities define priorities between the subscriber's criteria and thecriteria of others (e.g. groups, service providers etc.), and internalpriorities define priorities between conflicting criteria of thesubscriber himself/herself.

In the example of FIG. 14, the “others” whose criteria is prioritizedwith those of the subscriber include one group of which the subscriberis a member, the Concierge Provider and the subscriber's telephonecarrier. In this example, the criteria of the group take precedence overthe subscriber's criteria. At the same time, the subscriber's criteriatake precedence over those of the Concierge Provider and those ofhis/her telephone carrier. The telephone carrier's criteria in thisexample have the least priority, and will be ignored to the extent theygenerate any conflicts.

While, in this example, a given priority is applied to all of thecriteria of an entity identified in the External Priorities, thoseskilled in the art will appreciate that priorities can be assigned tospecific criteria of such entities (such as they are with internalpriorities, as described below). For example, cost limitations imposedin a group profile may be defined to take precedence over all of thesubscriber's preferences, but, so long as they are within these costparameters, vendor preferences of the subscriber may be defined to takeprecedence over vendor preferences of the group.

The Internal Priorities shown in FIG. 14 define priorities on acriterion by criterion basis. For example, in FIG. 14, the subscriber'srestaurant priorities are defined such that if a specific vendor isrequested by the subscriber at the time he/she makes his/her conciergerequest, that criterion has priority over all other criteria he/shemight have identified. Following such subscriber real time vendorselection, in descending order of priority for restaurant reservationrequests, are defined vendor preferences (as defined in the subscriber'spersonal profile), smoking preferences, credit card preferences, pricerange preferences etc. As indicated in FIG. 14, additional restaurantcriteria can be prioritized, as can criteria for any other type ofrequest the subscriber might make.

FIG. 14 is intended as an example of a CRA only. Those skilled in theart having the benefit of the instant disclosure will appreciate thatthere are many ways of implementing CRAs, that there are many types ofinstructions and other criteria which can be prioritized, thatconditional priorities can be implemented (e.g., “A” takes priority over“B” only if “C” is true), that inter-concierge request type criteriapriorities can be defined for complex transactions and the like (e.g.preferred airline takes priority over preferred car rental service),etc., all of which are within the scope of the instant invention.

In step 416 of FIG. 13, a determination is made whether the CRA accessedin step 414 resolved the conflict(s) identified in step 406. If so, theConcierge Provider attempts to fulfill the request in accordance withthis resolution in step 408, such as, for example, by proceeding to step216 in FIG. 10. Otherwise, the subscriber is notified of the conflict(s)in step 412.

In the example of FIG. 13, all conflicts are identified and resolvedwith respect to specific concierge requests after the subscriber hasrequested a concierge service. In some embodiments of the instantinvention, a similar conflict identification and resolution scheme isemployed at the time the subscriber sets up his/her personal profile. Inthis way, conflicts between the subscriber's stored criteria and thestored criteria of others can be resolved, to the extent possible,before the subscriber makes a request for service. While there areconflicts which cannot or will not be identified until such time as theconcierge request is made, resolving those conflicts which can beidentified based on stored criteria alone before a request is made willminimize future inconvenience to the subscriber.

The foregoing merely illustrates the principles of the invention. Itwill thus be appreciated that those skilled in the art will be able todevise numerous other arrangements which embody the principles of theinvention and are thus within its spirit and scope.

Finally, system 100 is disclosed herein in a form in which variousfunctions are performed by discrete functional blocks. However, any oneor more of these functions could equally well be embodied in anarrangement in which the functions of any one or more of those blocks orindeed, all of the functions thereof, are realized, for example, by oneor more appropriately programmed processors.

1. A method for providing a concierge-type service at a service providercomprising: (a) receiving a call at the service provider from a caller;(b) directing the call to an agent; (c) receiving a request for aconcierge-type service relating to an unidentified vendor from thecaller; (d) automatically determining information related to saidrequest; (e) using said information to identify an appropriate vendor;and (f) acting to fulfill said request as a function of said appropriatevendor.
 2. The method of claim 1, wherein said information relates to alocation of the caller.
 3. The method of claim 2, wherein said locationof the caller is determined using GPS technology.
 4. The method of claim1, wherein step (d) further comprises retrieving said information fromcomputer storage.
 5. The method of claim 4, wherein said informationrelates to one or more of: preferred vendors of the caller, preferredvendors of a group to which the caller belongs, caller preferredlocations for request fulfillment, preferred vendors of a conciergeprovider, preferred vendors of a telephone carrier, characteristics ofvendors the caller prefers, caller preferred service options, and cost.6. The method of claim 1, wherein said service provider comprises aninformation assistance service provider, and said agent comprises anoperator.
 7. The method of claim 1, wherein step (e) further comprisesconnecting said caller to said appropriate vendor.
 8. The method ofclaim 7, wherein step (e) further comprises attempting to fulfill saidrequest with said appropriate vendor.
 9. The method of claim 8, whereina fulfillment of said request is attempted in real time.
 10. The methodof claim 9, wherein said request is fulfilled offline if said requestcannot be fulfilled in real time.
 11. The method of claim 5, wherein atleast one of service provider preferred vendors and telephone carrierpreferred vendors pays a commission.
 12. The method of claim 5, whereinsaid cost comprises a cost of fulfilling said request with a vendor. 13.A method for selecting a vendor with which to attempt to fulfill aservice request, comprising: (a) receiving first vendor selectioncriteria from a user in conjunction with a user request; (b) accessingstored second vendor selection criteria; (c) determining if one or moreinconsistencies exist between two or more vendor selection criteria; (d)if no such inconsistencies exist, fulfilling said first request as afunction of third vendor selection criteria; and (e) otherwise, if saidone or more inconsistencies exist, obtaining information from which saidinconsistencies can be resolved, and fulfilling said user request as afunction of fourth vendor selection criteria and said information. 14.The method of claim 13, wherein said user request comprises a conciergerequest.
 15. The method of claim 13, wherein said second vendorselection criteria comprise at least user preferences.
 16. The method ofclaim 15, wherein said second vendor selection criteria further comprisepreferences of a service provider.
 17. The method of claim 16, whereinsaid preferences of a service provider comprise one or more of:preferences of a concierge provider, and preferences of a telephoneservice provider.
 18. The method of claim 13, wherein said third vendorselection criteria comprise at least said first vendor selectioncriteria.
 19. The method of claim 18, wherein said third vendorselection criteria further comprise said second vendor selectioncriteria.